Advanced Fog of War Feedback Thread 2.0

Wait, are you serious? How can this be a "New feature" if that's how it worked before the January update??  AFoW was revealed based on what the tokens could see, including external light sources... It's one of the things that broke in that update and now you are trying to say it never worked that way in the first place? A  software bug  is an error, flaw,  failure  or  fault  in a  computer program  or  system  that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. So either you are saying that it was not working as intended before the update (the way everyone expects it to behave) and that It actually got "fixed" by limiting the functionality to only reveal AFoW by the token controlled lightsource... or its a bug by definition and you are going from dodging the question to stating it would be a New feature...  Cmon now... Right below the post you linked is Brian C. with a Proof it worked before so please stop trying to lie to everyone that we have a mass delusion... We are your paying customers for crying out loud,I think we deserve a bit of respect not being lied to our faces.

I almost wrote a similar post but decided it was just not worth wasting my metaphorical breath. Thanks Stryxin

I was curious, so I looked up the history of the AFoW wiki page, from before January. Although as shown in this thread, having an external light clear AFoW was a previous behavior of the system, it does not seem to have been the intended behavior. At least I couldn't find anything in the documentation that mentioned it working this way. I don't think that this is deliberate falsehood, just a case of users finding a useful (though unintended) feature. Note: I don't use the feature (My group does not universally have powerful computers nor high technical aptitude). As such, I could have easily missed something. Also, I only looked at the last update to the wiki from the previous year, not an exhaustive search.

In the process of re-optimizing Advanced Fog of War to facilitate performance improvements and interaction with Dynamic Lighting, we continue to have unintended and undocumented use cases be… brought to light. :P Advanced Fog of War used to work by checking every cell on the map to see if player controlled tokens had vision there. For many users, this slowed Roll20 to a halt. With Get a New Look , we refactored the system so that it no longer checked every square: now it measures out from the player controlled tokens and then checks for any obstructions like Dynamic Lighting. This efficiency opened Advanced Fog of War to a lot more people. However, the fact that the system no longer checks every cell means that when it checks on a token that doesn’t have any direct vision, it goes “oh, I don’t have to measure out anything for this token.” That’s why the token is plunged back into darkness if the light source disappears. Reverting to the previous method of checking every cell would make Advanced Fog of War slow and (for many) unusable again, but we understand that the unintended use case here served other needs. If you used Advanced Fog of War in this way, it would help us if you could explain what you were trying to do (such as share a torch between multiple party members) so we can look at new ways to solve that need! Our dev team will be diving back in to take a look at what we can create here, and we will keep you posted about what we find.

Cavni said: [edited for brevity] Reverting to the previous method of checking every cell would make Advanced Fog of War slow and (for many) unusable again, but we understand that the unintended use case here served other needs. If you used Advanced Fog of War in this way, it would help us if you could explain what you were trying to do (such as share a torch between multiple party members) so we can look at new ways to solve that need! Our dev team will be diving back in to take a look at what we can create here, and we will keep you posted about what we find. It only makes sense that a token that emits light should reveal cells that are in line of sight by a token with sight. It may not have been intended, but the effect is logical and practical. To claim we have to go through the crap shoot that is the Suggestions Forum to regain such a basic function is rather insulting IMHO. You can call it "bug" or "feature" however you want, but grandfather it into the list of features in development so us paying customers can stop feeling like we're being given the shaft.

I am grateful for the continued updates and ongoing dialogue on this issue. However, this needs a little unpacking: Cavni said: Advanced Fog of War used to work by checking every cell on the map to see if player controlled tokens had vision there.  i.e. it used to work as you would expect a fog of war system to work, by any reasonable definition of the term, by revealing the fog in areas of the map seen by that character's token. Cavni  said: With  Get a New Look , we refactored the system so that it no longer checked every square: now it measures out from the player controlled tokens and then checks for any obstructions like Dynamic Lighting.  So what you have done instead is to approximate the expected behaviour of a fog of war system, for performance improvements. As a result of that approximation you have lost some of the fundamental functionality you previously provided. Cavni  said: ...we understand that the unintended use case here served other needs.  Trying to spin the proper behaviour of your previously implemented fog of war system as "unintended" is disingenuous at best and insulting at worst. Insisting that restoring it should be a feature request rather than a big fix is frankly untenable. Cavni  said: However, the fact that the system no longer checks every cell means that when it checks on a token that doesn’t have any direct vision, it goes “oh, I don’t have to measure out anything for this token.” That’s why the token is plunged back into darkness if the light source disappears. This specific check sounds like a big part of the problem, and surely overriding this would require the expected behaviour? If not, at least allow GMs the choice between the old (functional) system and the new (light-weight but broken) system when configuring their games/maps. I am, however, grateful that we seem to have moved on from trying to gaslight users into believing it never worked in the way that we all remember it. And yes, sharing a torch between party members is a perfect example of the issue. I think everyone is well aware of that. Others are static light sources on the map (i.e. a lantern on the wall, candle on the table, bonfire on the clearing etc.) and global illumination, of course.

Simple rule; Fog of War:  What a character's token has seen, stays revealed. I wouldn't forget the shape of a room just because my buddy was the one carrying the torch.

was running some pre game tests with AFOW and it turns out circles are causing issues with token line of sight that is to say circles do not properly in-force sight barriers, but squares and other shapes do. i used polygon instead. thought i would relay this as the fix seems logical and simple. In addition to saving lots of people lots of aggro 

DMG said: was running some pre game tests with AFOW and it turns out circles are causing issues with token line of sight that is to say circles do not properly in-force sight barriers, but squares and other shapes do. i used polygon instead. thought i would relay this as the fix seems logical and simple. In addition to saving lots of people lots of aggro  Good point. The curves do weird things to the line of sight tracing. The recommended technique is to use squares and polygons as you say.  The wiki warns against using circles for dynamic lighting lines , but it could probably benefit from occasional mention in the forum, as not everyone reads the wiki.

Prior to Jan. 29, AFoW worked the way a reasonable human being would expect it to work. If two tokens were in the same area, but one had a torch and the other did not, AFoW cleared for both of them, because as Chris S. says, you wouldn't forget what a room looked like just because someone else was holding a torch. This is a basic, basic, basic use case -- one that comes up every session. It is not a niche case that you can justify omitting. AFoW as it exists now, for all intents and purposes, may as well be nonfunctional, because it is useless to me from a practical standpoint. The fact that Roll20 spent months pretending all was well (gaslighting) and is now pretending that gaining back the feature that made AFoW usable in the first place should be a feature request (!) is insulting and disturbing. This is not how you treat paying customers. Admit the mistake, fix the error, and then work on regaining your customers' trust. 

My players have identified an odd issue with AFoW that we had not had previous to the latest updates. Maps with AFoW on cause tokens to appear "translucent". I also tried this on the dev server, but had the same experience. Is this a known issue with any kind of work around? I can provide screenshots or further information as needed. Thanks!

I finally have a big enough break to respond to this. Thanks, Cavni, for opening up the thread to use cases. Cavni  said: In the process of re-optimizing Advanced Fog of War to facilitate performance improvements and interaction with Dynamic Lighting, we continue to have unintended and undocumented use cases be… brought to light. :P Take 1d12 pun damage. :) Advanced Fog of War used to work by checking every cell on the map to see if player controlled tokens had vision there. For many users, this slowed Roll20 to a halt. With  Get a New Look , we refactored the system so that it no longer checked every square: now it measures out from the player controlled tokens and then checks for any obstructions like Dynamic Lighting. This efficiency opened Advanced Fog of War to a lot more people. I think I had a very different experience compared to some people. AFoW never really had bad performance for me before the rewrite. Sometimes it may have been slightly slower, but in general it worked well. In contrast, for basic use cases (i.e. 5e darkvision), the new system works well, but there are times when it grinds to halt in ways that I never experienced before the rewrite. The most significant slowdown I have experienced is when AFoW and Global Illumination are on at the same time, a combination that was not problematic before the rewrite. Indeed, the bug reports for massive slowdowns on large maps seemed to spike after a March 29 patch: March 29: Fixed an issue where AFoW did not reveal using DL vision radius multiplier Fixed an issue where Tokens with sight did not have infinite-ranged AFoW vision when Global Illumination is on Before that, I never had a problem with AFoW and Global Illumination, and I suspect no one had a problem between Jan 29 and March 28 because AFoW was only checked in a limited radius around the token. However, the fact that the system no longer checks every cell means that when it checks on a token that doesn’t have any direct vision, it goes “oh, I don’t have to measure out anything for this token.” That’s why the token is plunged back into darkness if the light source disappears. Reverting to the previous method of checking every cell would make Advanced Fog of War slow and (for many) unusable again, but we understand that the unintended use case here served other needs. If you used Advanced Fog of War in this way, it would help us if you could explain what you were trying to do (such as share a torch between multiple party members) so we can look at new ways to solve that need! Our dev team will be diving back in to take a look at what we can create here, and we will keep you posted about what we find. An Example of the Original AFoW Behavior So now, why did I never have a problem with AFoW performance? I suspect there were a few reasons: Only player-controlled tokens had vision. I am not sure, but I suspect that NPC tokens with vision were causing the engine to go through additional AFoW calculations before the rewrite. I used an optimization that I now think the Roll20 team did not expect / intend. I used the token's View Distance for every player-controlled token with vision whether it generated it's own light or not. The first may or may not have helped, but I believe the second is why I never really had issues with AFoW. The following example is intrinsic to how I understood AFoW to work before the rewrite. I keep coming back to it because: It is from a product I released around September 2018, and the image is from the product page on the marketplace. I am able to create a clean game that has the settings as they were when the promo image was captured. It has a minimum of moving parts. There are only two tokens and no DL lines. In the following image, it looks like a player token is moving across a map and clearing fog of war. In actuality, that token emits light but is only controlled by the GM. The players control a 1-pixel token hidden in the corner of the map (shown selected). As the party explores the map, the GM moves the light token, changing what the players can see, and clearing fog of war. The tokens had the following ownership settings. The player token is on the left, and the light token is on the right. Then the vision settings. Again, player on the left, light token on the right. Notice that the player token has a reveal distance that covers the entire map. What I came across is that fog of war would not be cleared for the players if the player-controlled token had a blank View Distance. If I set the player token's View Distance to 100 miles and then moved the light token every square on the map at least once before returning it to the center, I got a result that looked like the following mock up (imagine the stair-step reveal of the fog of war border). The fog of war was cleared by the external light source, but only within the player token's View Distance. What I Think Was Happening I play D&D 5e, and the usual Darkvision distance is 60 feet. I set the AFoW View Distance to 60 feet on every player token whether the token emitted light or not. I believe this is why I never really had performance issues with AFoW and why all the tokens, including those that did not emit light, had AFoW clear fog of war. Whether the token's were on a map with torches everywhere, a single token projecting moonlight, a torch token the moved along with them, or Global Illumination, AFoW would clear fog of war for a player on illuminated squares within 60 feet of their token. It was not perfect; light further than 60 feet from the player token did not clear fog of war. However it worked regardless of the lighting on the map, and 60 feet was usually good enough. I suspect the following quote from the AFoW entry in the wiki (taken from September 2018) was coming into play: Any value entered in the View Distance under the Advanced Fog of War section will supersede any value you have in Emits Light. When I first started playing with AFoW, I must have started with a token that did not emit light, because I found that the token's View Distance had to be set to get fog of war to clear. I then assumed that was the requirement for every player token, including those that emitted light and assumed that View Distance was used as a lever to balance performance vs how much fog of war was revealed. I never realized that tokens that emitted light did not need the View Distance set until after the rewrite. I suspect that one of the places where performance was bad before the rewrite was on pages with AFoW and Global Illumination. That seems like a prime place where, as Cavni indicated, AFoW would check every square. On a large map, that might take a while, but my players and I never seemed to have a lot of trouble with that. I suspect that setting the View Distance of the tokens limited the scope of the AFoW checks, even with Global Illumination activated. Suggestion for Restoring the Desired Behavior I see restoring the behavior of the player token's View Distance (now Reveal Distance) as fundamental to restoring the overall behavior of AFoW. Before the rewrite, View Distance restricted the scope of AFoW calculations on a map with Dynamic Lighting activated. I never used AFoW on its own; I did not even realize that was a possibility. My guess is that the behavior of the token's View Distance after the rewrite is the same as if AFoW had been used without DL before the rewrite: fog of war is cleared within the View Distance radius around the token. Having View Distance always clear fog of war within that radius of the token seems like a good choice while DL is off. However while DL is activated it is blocking the desired behavior of fog of war because the setting provided some important functions before. I believe that implementing the following changes would place AFoW in a position to make the maximum number of people happy: Change Reveal Distance to limit the scope of AFoW calculations for a player to within its range rather than just clearing fog of war. This would allow customers to limit the performance hit from AFoW even on maps with Global Illumination. A 60-foot Reveal Distance would cause a number of squares to be checked as shown in the following picture. A 60-foot View Distance comprises a square with 25-square sides and 625 grid squares. 136 of those are outside of the radius (34 per corner). This means 489 grid squares would be checked to see if they were illuminated as opposed to the thousands of squares on larger maps. Do not have Global Illumination override a token's View Distance, at least not when it has been set by the user. I suspect that this will avoid the problem with AFoW and Global Illumination on large maps like Storm King's Thunder 's Eye of the All Father map. A token must have "Has Sight" checked to contribute to clearing fog of war with AFoW. Decide what the default Reveal Distance should be when a token has sight and the Reveal Distance. Possible values are 0 or a user-entered value on the game or page settings. Tokens that emit light could also default to the range of their light (bright or dim light based on the page settings). Add a note to the wiki that Reveal Distance clears fog of war when DL is off and limits the range of checks when DL is on. Implementing these changes should get scenarios such as the following working again: My overland map described above. A party carrying a torch token through a dark dungeon. As long as the player tokens stay within a reasonable distance of the torch token, fog of war is cleared. AFoW and Global Illumination as described above. A 5e human walking from a lit room to a dark corridor to another lit room. Only the two rooms and a bit of the corridor would show up as cleared in fog of war. A player token emitting directional light such as from a flashlight or hooded lantern. Only the illuminated squares in front of the token should be cleared in fog of war.

Another impeccable post Brian - it's really impressive the amount of effort you put into testing and documenting these issues. Frankly, Roll20 should be paying you for this, but I just wanted to say thanks on behalf of other users like me. Having read through your post, I agree that the approach you proposed would work for my use case, as well as all the others I can think of. In fact, it sounds a lot like the old system, but constrained to checking and revealing the fog of war within a player-defined radius of each token with sight, rather than over the whole map. I also want to add that in my experience, neither myself or my players suffered any performance issues under the old system, but I'm willing to believe that some people might have. I guess it might also support making more functionality available on tablet clients, for example. Still, it seems a shame to severely reduce the functionality available to all users, just to help performance on very constrained systems. 

Yep, I never had performance issues either on the old system. And thank you so much, Brian, for all the testing, documenting, and summarizing of this persistent issue.

I should have spoken more directly: it was my mistake to recommend the Suggestions Forum for this issue when Drespar brought it to my attention, and we are now looking at ways to address the examples from this thread in the short term. We learned that our internal documentation on this advanced feature wasn’t keeping up with the way many people were using it, and we know that we need to do better about that to prevent such mistakes. Even though Advanced Fog of War wasn’t designed with third-party reveal functions in mind, we understand why people expect it and want to support that moving forward. We’d like to do this in a way that does not require performance-slowing workarounds but is, instead, built into the system. In my last post, I wanted to give context on why we changed the old system. Checking every cell is an onerous process that slows down the tabletop, and returning to that method would once again make Advanced Fog of War unusable for people with slow connections or low-spec computers (some 40% of Roll20 users). Within the scope of our new calculation method, though, we believe we can address the use cases that have been described in this thread and that’s what we’re researching now. Regarding the issue raised by Jp R.: yes please to screenshots, posted here on the thread or emailed to <a href="mailto:team@roll20.net" rel="nofollow">team@roll20.net</a> ! The issue you’re reporting is a new one to me, and I’d like to dig into it as well.

Nice one, mate. Great post. I too was limiting distance for every PC, and never had sight turned on for NPCs. AFoW ran absolutely fine, even on my fairly crappy laptop, and I use some quite intense maps. Brian C. said: (A lot)

As requested, I have screenshots: First, an example of the issue. This is the view from the human token, notice the Tabaxi and Half-Orc tokens are semi-transparent. This is most noticeable on the Half-Orc, with the line of the door showing through the token. Next two are the map settings with AFoW and the token settings: These are the defaults I usually use, but I have tried adjusting most of the AFoW settings, and tried other Token settings, but the behavior above seems to continue.&nbsp; Lastly, a comparison with only dynamic lighting, and no fog of war, advanced or otherwise. The tokens are much more solid, as we expect: Also note that the light sources seem to have gone away when AFoW is on, almost like the light layer is being placed below the AFoW. For additional information this campaign is running the Waterdeep Mad Mage module, the map in screenshots is level 2, but we tested this on other levels as well.

Jp R. said: As requested, I have screenshots: First, an example of the issue. This is the view from the human token, notice the Tabaxi and Half-Orc tokens are semi-transparent. This is most noticeable on the Half-Orc, with the line of the door showing through the token. Next two are the map settings with AFoW and the token settings: These are the defaults I usually use, but I have tried adjusting most of the AFoW settings, and tried other Token settings, but the behavior above seems to continue.&nbsp; Lastly, a comparison with only dynamic lighting, and no fog of war, advanced or otherwise. The tokens are much more solid, as we expect: Also note that the light sources seem to have gone away when AFoW is on, almost like the light layer is being placed below the AFoW. For additional information this campaign is running the Waterdeep Mad Mage module, the map in screenshots is level 2, but we tested this on other levels as well. Hey Jp R., for the second part of your post, where light sources get washed out, do you think you are running into the issue described here?&nbsp; <a href="https://app.roll20.net/forum/permalink/7510768/" rel="nofollow">https://app.roll20.net/forum/permalink/7510768/</a> In that post I show a comparison of what cleared fog of war used to look like before the rewrite compared to how bright it is now. The final two images are side-by-sides of GM and player views (GM on left, player on right). The first shows cleared fog of war washing out the lights, and the second shows the same scene with just Dynamic Lighting.

Team... this is just unreal. Something is deeply wrong with your process. I'm sure everyone is working very hard, but the fact that the 5 (!) months spent working on this fix failed to address users' valid complaints indicates that the product planning and acceptance testing process did not work. The way this is supposed to function is as follows: Ask users what their pain points / use cases are. Write a product spec. Write a design doc around that spec. Build the feature. Perform internal user acceptance testing. Submit it to a limited set of outside testers for feedback. Go live. If either 1 or 6 had been done, we wouldn't be here. It's clear this isn't what your users were asking for, and it's evident that as a result they're not satisfied. Please, folks, take a deep breath, slow down, and be more deliberate with what you're building. People like me are running out of good faith and trust.

Gabriel Foster said: Team... this is just unreal. Something is deeply wrong with your process. I'm sure everyone is working very hard, but the fact that the 5 (!) months spent working on this fix failed to address users' valid complaints indicates that the product planning and acceptance testing process did not work. The way this is supposed to function is as follows: Ask users what their pain points / use cases are. Write a product spec. Write a design doc around that spec. Build the feature. Perform internal user acceptance testing. Submit it to a limited set of outside testers for feedback. Go live. If either 1 or 6 had been done, we wouldn't be here. It's clear this isn't what your users were asking for, and it's evident that as a result they're not satisfied. Please, folks, take a deep breath, slow down, and be more deliberate with what you're building. People like me are running out of good faith and trust. +100

Brian C. said: Hey Jp R., for the second part of your post, where light sources get washed out, do you think you are running into the issue described here?&nbsp; <a href="https://app.roll20.net/forum/permalink/7510768/" rel="nofollow">https://app.roll20.net/forum/permalink/7510768/</a> In that post I show a comparison of what cleared fog of war used to look like before the rewrite compared to how bright it is now. The final two images are side-by-sides of GM and player views (GM on left, player on right). The first shows cleared fog of war washing out the lights, and the second shows the same scene with just Dynamic Lighting. It's entirely possible,to be the same but I do not know.&nbsp; I think something with the layering of Canvases they are using changed (z-order), or that they aren't masking properly between them. Right now it looks like the AFoW cares not for your dynamic lights, in either case.

Jp R., thank you for that detailed report! It helped our devs reproduce the issue and they are investigating further. We also changed the Token Z-Order with the new patch released today . This has been in testing on the dev server since June 7th to gather some additional feedback and should address tokens and token bars being obscured by lighting/fog effects. We had a particular focus on accessibility for players with this change, so you will notice that so long as your token has sight it will render in front of other tokens as well as in front of any Advanced Fog of War and Dynamic Lighting effects. This makes sure your token can be quickly picked out of a busy scene! Please keep us updated with any feedback so we can continue to make improvements in these areas. At present, our dev team is researching solutions to allow for all visible light to contribute to a token's revelation of Advanced Fog of War.

Hi Cavni, Thanks for the update. A few weeks ago I posted that the areas AFoW cleared were so bright they were overwhelming the light from Dynamic Lighting. At the time, it was dismissed as beind dependent on my system (monitor contrast, video card, etc.) and I was directed to add my voice to a suggestion about global illumination. However, I think Jp R.'s post shows that it is not tied to the system but rather the light intensity level. Before the rewrite, AFoW was the same intensity as dim light. After the rewrite, it has the same intensity as bright light. This causes dim light to be replaced with bright light, as shown in my previous post, Jp R.'s post, and this clip from the recent Roll20 Indie Showcase for the Grimmerspace Kickstarter. Around the 20 second mark you see the dim light for the room for just a moment before the AFoW kicks in. <a href="https://clips.twitch.tv/BillowingSpoopyFloofDendiFace" rel="nofollow">https://clips.twitch.tv/BillowingSpoopyFloofDendiFace</a> The adventure in the clip is supposed to be a spooky/scary scenario in a horror genre, but the level of tension is lowered when the room appears brightly lit.

I will second this.&nbsp; Areas cleared by AFoW are way too bright and it's hard to tell on some maps that it's not being illuminated. The only clue is that the grid lines are missing. I am also experiencing the issue of semi-translucent tokens on the object layer when using AFoW. The doors on my maps all look like ghosts.&nbsp;

Third this issue. AFoW areas cleared are too bright. Please fix.

Since I was ignored two times already: I do not believe that performance increased at all with the update. In fact, Dynamic Lighting and FoW are now borderline unusable for me. I can reliably test this on a pretty big map I made some time ago. Before the update it worked flawlessly. Now, everytime a token with sight is moved, it lags for 1 second. This time adds up for every token moved! (3 tokens take more than 3 seconds!) No, the map does not have Global Illumination. Then I had to revert to normal FoW. But no, that was broken too until recently... I am starting to be sincerely disappointed in roll20.

While Advanced FoW and Dynamic lighting are on, rooms that my players have visited show up white instead of desaturated, also shadows sometimes appear white as well. This is using the official ToA Adventure.

Thanks for the feedback on the brightness level. We had tried an adjustment due to visibility concerns we'd received and need to take another look to try and find a happy medium. The devs are working on a revision and will put it on the Dev server when it's complete. We'll let you know when it's there for testing so we can get your feedback before it goes live.

Bunny said: Thanks for the feedback on the brightness level. We had tried an adjustment due to visibility concerns we'd received and need to take another look to try and find a happy medium. The devs are working on a revision and will put it on the Dev server when it's complete. We'll let you know when it's there for testing so we can get your feedback before it goes live. Thanks, Bunny! Getting proposed changes on the Dev server is always welcome. Sometimes we may miss evaluating a change (I missed the first month &nbsp;of the AFoW update because I was working on something else), but it really helps to have some time to evaluate a change before it becomes official. I feel the Token Bar fix was better because it had some time to cook on the Dev server.

I have found another issue. This issue has come up a few times and im not sure if its related to the change or not. But I keep having an issue where I am unable to select a pre-drawn Shape/Polygone/line ect. Really annoying whem im trying to move a "door" line that blocks lighting/sight out of the way and i can select it. It normally happens if I scale down the shape after i draw it. or sometimes when im using "thin" lines it happens. Their is no cursor change when i hover over it, and even if i draw a bounding box oven the entire shape it wont select it. Zooming in sometimes helps, but I have a few lines that are now permanently on my maps which I can not move or get rid of. Im guessing you will need to page info where the issue is, i remember hearing something about how to link that but im not sure how to. Unless its a known issue but isnt part of this thread.

00zim00 said: I have found another issue. This issue has come up a few times and im not sure if its related to the change or not. But I keep having an issue where I am unable to select a pre-drawn Shape/Polygone/line ect. Really annoying whem im trying to move a "door" line that blocks lighting/sight out of the way and i can select it. It normally happens if I scale down the shape after i draw it. or sometimes when im using "thin" lines it happens. Their is no cursor change when i hover over it, and even if i draw a bounding box oven the entire shape it wont select it. Zooming in sometimes helps, but I have a few lines that are now permanently on my maps which I can not move or get rid of. Im guessing you will need to page info where the issue is, i remember hearing something about how to link that but im not sure how to. Unless its a known issue but isnt part of this thread. I have found that short, straight, thin lines can sometimes seem unable to be selected. However, if you were to use Ctrl+A to select everything followed by the Del key will delete it along with every other DL line. What I have found is that selecting an empty grid square nearby will select the line. The problem is that it is trial and error to find where the square actually is. To avoid this with doors, I put a tail on the door. I have found the problem to not manifest itself if the DL line is more than just a short, straight line, like in the following picture. I should also mention that I think this issue has been around since before the AFoW rewrite.

Jake said: While Advanced FoW and Dynamic lighting are on, rooms that my players have visited show up white instead of desaturated, also shadows sometimes appear white as well. This is using the official ToA Adventure. Hi Jake, just a shot in the dark, but I was wondering if there was any mostly transparent overlay on your map. I was noticing a similar effect, which I think may have come about as part of the "player-controlled token on top" update. Tokens that are not controlled by a player are now see through except where they are in a room with Dynamic Lighting. In this image the spider has been stretched to cover multiple rooms. The portions that cover an illumination room show up solid.

Drespar said: Gotcha. Re-drawing the lines on my end results in the problem abating, which leads to a few extra questions-- If you redraw the lines in the copy, do you still run into the same issue? Are you using anything other than a mouse and keyboard to draw the dynamic lighting lines? (i.e. pen and tablet, touch, etc.) Is this the only game where you have run into the issue? If possible, could you create a new game and try to re-create this issue there? I think I figured out what caused the Dynamic Lighting lines to misbehave on that maze, but I don't know why it did it. I had started with a 32x20 map. When I realized the minotaur would have to squeeze through the 5-foot-wide corridors, I expanded the map to 64x40, selected all the DL lines, and resized them en masse &nbsp;to match the enlarged maze.

Has there been any progress on fixing the interaction between dynamic lighting and advanced fog of war?&nbsp; Specifically the issue that sight does not reveal the AFoW if the token itself is not the light source.&nbsp; It's been almost a month since the last substantive update and I'm still having to tell my players that after six months, this core functionality is still broken.&nbsp;&nbsp;

A few weeks ago, Brian offered an incredibly helpful and thorough description of the AFoW problem, along with a a series of suggestions for restoring the right AFoW behavior that existed prior to the Jan. update. It is now July. Have the devs looked at these suggestions at all? Is there a plan and a timeline for implementing these changes? I am honestly baffled by the lack of transparency in this process. Brian C. said: &lt;snip&gt; Suggestion for Restoring the Desired Behavior I see restoring the behavior of the player token's View Distance (now Reveal Distance) as fundamental to restoring the overall behavior of AFoW. Before the rewrite, View Distance restricted the scope of AFoW calculations on a map with Dynamic Lighting activated. I never used AFoW on its own; I did not even realize that was a possibility. My guess is that the behavior of the token's View Distance after the rewrite is the same as if AFoW had been used without DL before the rewrite: fog of war is cleared within the View Distance radius around the token. Having View Distance always clear fog of war within that radius of the token seems like a good choice while DL is off. However while DL is activated it is blocking the desired behavior of fog of war because the setting provided some important functions before. I believe that implementing the following changes would place AFoW in a position to make the maximum number of people happy: Change Reveal Distance to limit the scope of AFoW calculations for a player to within its range rather than just clearing fog of war. This would allow customers to limit the performance hit from AFoW even on maps with Global Illumination. A 60-foot Reveal Distance would cause a number of squares to be checked as shown in the following picture. A 60-foot View Distance comprises a square with 25-square sides and 625 grid squares. 136 of those are outside of the radius (34 per corner). This means 489 grid squares would be checked to see if they were illuminated as opposed to the thousands of squares on larger maps. Do not have Global Illumination override a token's View Distance, at least not when it has been set by the user. I suspect that this will avoid the problem with AFoW and Global Illumination on large maps like Storm King's Thunder 's Eye of the All Father map. A token must have "Has Sight" checked to contribute to clearing fog of war with AFoW. Decide what the default Reveal Distance should be when a token has sight and the Reveal Distance. Possible values are 0 or a user-entered value on the game or page settings. Tokens that emit light could also default to the range of their light (bright or dim light based on the page settings). Add a note to the wiki that Reveal Distance clears fog of war when DL is off and limits the range of checks when DL is on. Implementing these changes should get scenarios such as the following working again: My overland map described above. A party carrying a torch token through a dark dungeon. As long as the player tokens stay within a reasonable distance of the torch token, fog of war is cleared. AFoW and Global Illumination as described above. A 5e human walking from a lit room to a dark corridor to another lit room. Only the two rooms and a bit of the corridor would show up as cleared in fog of war. A player token emitting directional light such as from a flashlight or hooded lantern. Only the illuminated squares in front of the token should be cleared in fog of war.

Jay R. said: A few weeks ago, Brian offered an incredibly helpful and thorough description of the AFoW problem, along with a a series of suggestions for restoring the right AFoW behavior that existed prior to the Jan. update. It is now July. Have the devs looked at these suggestions at all? Is there a plan and a timeline for implementing these changes? I am honestly baffled by the lack of transparency in this process. In their Roundtable a couple of weeks ago, they said the below information (my paraphrase/notes distilling the conversation). I'm not sure how many of the issues/suggestions Brian raised are on the table, but it sounds like they need to go back to the drawing board and there might be another major AFoW overhaul before all is said and done.&nbsp; Roll20 is aware (Nolan uses the word "embarrassing") that functionality has been lost with Advanced Fog of War in the updates because they were not aware enough of how users we utilizing the functions. They need to go back to the drawing board in some ways to get things right before launching the Layer Up update (or any other updates that hinge on this function). It sounds like AFoW will have more major overhauls coming now that it has been patched into a usable state again. This may also include re-branding the tools to help with naming confusion issues. Apparently their recent The Rundown video has some info on their process of how they have been working on the AFoW fixes.

I am hoping for the rebranding at the very least. Fog of War and Advanced Fog of War for two entirely different features is difficult to explain to folks. FoW should be named "Masking" or "Concealment".

keithcurtis said: I am hoping for the rebranding at the very least. Fog of War and Advanced Fog of War for two entirely different features is difficult to explain to folks. FoW should be named "Masking" or "Concealment". They still do largely the same thing, and FoW is the VTT equivalent of what a GM would likely do at an IRL table. What about renaming AFoW as "Automatic/Automated Fog of War"?

I think AFoW has bigger issues than what its called right now. It functionally doesn't work for many people. A rebranding isn't going to solve that.

Loren the GM said: Jay R. said: A few weeks ago, Brian offered an incredibly helpful and thorough description of the AFoW problem, along with a a series of suggestions for restoring the right AFoW behavior that existed prior to the Jan. update. It is now July. Have the devs looked at these suggestions at all? Is there a plan and a timeline for implementing these changes? I am honestly baffled by the lack of transparency in this process. In their Roundtable a couple of weeks ago, they said the below information (my paraphrase/notes distilling the conversation). I'm not sure how many of the issues/suggestions Brian raised are on the table, but it sounds like they need to go back to the drawing board and there might be another major AFoW overhaul before all is said and done.&nbsp; Roll20 is aware (Nolan uses the word "embarrassing") that functionality has been lost with Advanced Fog of War in the updates because they were not aware enough of how users we utilizing the functions. They need to go back to the drawing board in some ways to get things right before launching the Layer Up update (or any other updates that hinge on this function). It sounds like AFoW will have more major overhauls coming now that it has been patched into a usable state again. This may also include re-branding the tools to help with naming confusion issues. Apparently their recent The Rundown video has some info on their process of how they have been working on the AFoW fixes. Thanks for the info, Loren. Appreciated. I tend to agree with the point of view that rebranding is the least of the problems right now. But at least they know just how big of a fiasco this AFoW issue has been for them -- the word "embarrassing" is entirely appropriate -- so that's a start. Having said that, if I were to rebrand, I'd just make a simple distinction: Manual Fog of War and Automatic Fog of War.

Hey all, We want to let you know that we are in the midst of heavy research to improve the communications between Dynamic Lighting and Advanced Fog of War. It's pretty far-ranging and as soon as we have any updates to share or something to test on the Dev server, we will let you know. Thank you for all of your feedback!

Im having an issue with AFoW and DL where the DL is working correctly and not going past barriers. Everything looks like it should in DL. But for some reason there are 'Shine Paths' where AFoW reveals the shaded areas beyond where DL is hitting a boundary. Example, a token in a room shows only the room for DL but in some spots beyond the lighting the AFoW will show beyond the boundary as shaded like the token has seen the area before even when it has not. Not sure if this is a known issue.&nbsp;

Joshua M. said: Im having an issue with AFoW and DL where the DL is working correctly and not going past barriers. Everything looks like it should in DL. But for some reason there are 'Shine Paths' where AFoW reveals the shaded areas beyond where DL is hitting a boundary. Example, a token in a room shows only the room for DL but in some spots beyond the lighting the AFoW will show beyond the boundary as shaded like the token has seen the area before even when it has not. Not sure if this is a known issue.&nbsp; I have experienced something similar to this when the DL lines have been resized or otherwise altered. I had to redraw the lines that had been resized.

Brian C. said: Joshua M. said: Im having an issue with AFoW and DL where the DL is working correctly and not going past barriers. Everything looks like it should in DL. But for some reason there are 'Shine Paths' where AFoW reveals the shaded areas beyond where DL is hitting a boundary. Example, a token in a room shows only the room for DL but in some spots beyond the lighting the AFoW will show beyond the boundary as shaded like the token has seen the area before even when it has not. Not sure if this is a known issue.&nbsp; I have experienced something similar to this when the DL lines have been resized or otherwise altered. I had to redraw the lines that had been resized. Thanks Brian! This could be it. I did resize a lot of lines on the map I was using. This worked for me thanks!

Joshua M. said: Thanks Brian! This could be it. I did resize a lot of lines on the map I was using. This worked for me thanks! You are welcome. :)

Hi! Using DL and Advanced Fog of War dramatically slows the game. Did u find a fix to this issue? I enclose u a short Gif as an example. Thank u guys!

Yeah, DL and AFoW are very slow at the moment. Also, AFoW doesn't work with NPCs as per a test of mine today. An NPC armed with a torch and AFoW and DL enabled on two different maps had nothing "saved" in AFoW when the token moved away from an area they'd already explored. Basically it was like Dynamic Lighting was working, but AFoW was not. Did not have this issue with PCs.

Jay R. said: Yeah, DL and AFoW are very slow at the moment. Also, AFoW doesn't work with NPCs as per a test of mine today. An NPC armed with a torch and AFoW and DL enabled on two different maps had nothing "saved" in AFoW when the token moved away from an area they'd already explored. Basically it was like Dynamic Lighting was working, but AFoW was not. Did not have this issue with PCs. I think fog of war is only cleared for tokens controlled by players unless the AFoW-&gt;All Tokens Reveal box is checked. Is that box checked on the page?