Animations and AFoW Offical Feedback Thread

Hi, Phil. I'm not sure why you think you'd be punished. I've only ever banned one person, and it was due to an accidental mouse-click. We now have a third-party team ("ModSquad") that handles code of conduct complaints, and for my part, I think people in this thread have been fairly respectful and polite. Mostly, I've been reading the comments about a rollback and considering what impact that would have. It's also ultimately not a decision I would make alone. Since there isn't much for me to say at this time about that kind of move, I haven't replied to those comments. Sometimes it's better to listen. As I said a week ago: we don't push code on weekends. We're working quickly to fix bugs, and I think the Tuesday code push (one way or another) will alleviate a lot of these concerns. Phil said: Odd to notice how, despite the Roll20 mod responding to something else in this thread, they have chosen to ignore the roll it back comment despite all the people echoing it and agreeing. This update and the handling of it isn't giving me much confidence, especially after my confidence was already damaged in the Nolan fiasco, and I fully expect to get punished for saying so. Daniel H. said: I'm using advanced fog of war and dynamic lighting in a game im running, i can test run it with 1 player and it all run smoothly, the second all of us (7 in total) try and play the fog becomes completely unplayable, lagging terribly and even freezing and crashing completely sometimes requiring us to reload. That sounds pretty bad, Daniel. Can you reply with the game ID of the game you're playing so we can take a look and see if there's something causing that to happen? There's an odd error with image swapping that was reported earlier last week that we are trying to track down.

I've discovered that one of the issues I've been encountering is related to the visual presentation of the advanced fog of war's revealed areas. The areas that have been revealed to a player will remain, as expected, but the image used to show this area is just a gray scale version of the page. This means that images used on the page that are low brightness, or saturation, blend in with the gray scale image, which significantly impacts the visual representation of an area with dynamic lighting. Advanced fog of war off Advanced fog of war on:  Because the gray scale image blends into the room, it begins to look like there's no dynamic lighting at all. It would be nice if I could control the brightness of the revealed fog of war area. It also seems that the old methods of making soft lights with negative values in the dim light field have changed and no longer produce the same results which is a major bummer.

Stephanie's response makes sense to me, doing a rollback verse trying to push through with hot fixes is a double edged sword and a decision better left to business managers or other leadership. There are a long list of variables to consider; time|money|effort|perception|liability|future needs and probably a million other things. I also imagine I'm not the first to consider the idea of a rollback but I'm hoping the platform doesn't have to save against a sunk cost trap and try to patch it's way through this and have it take 6 weeks to resolve. Cheers -Snow Stephanie B. said: ... Mostly, I've been reading the comments about a rollback and considering what impact that would have. It's also ultimately not a decision I would make alone. Since there isn't much for me to say at this time about that kind of move, I haven't replied to those comments. Sometimes it's better to listen. ... Phil said: Odd to notice how, despite the Roll20 mod responding to something else in this thread, they have chosen to ignore the roll it back comment despite all the people echoing it and agreeing. This update and the handling of it isn't giving me much confidence, especially after my confidence was already damaged in the Nolan fiasco, and I fully expect to get punished for saying so.

I've been watching the progress of this thread with some interest. I have a few observations: I doubt a rollback is in anyone's interests right now. For an update of this complexity, I suspect that the consequences of rolling it back may end up being worse than fixing the bugs unless Roll20 have an insanely advanced deployment process. I get why people are asking but I honestly don't think it's going to help. In the long run, I really think you guys need a proper ticketing system (something tells me this will have been discussed). Stickied forum threads with a manually updated "known issues" list on the OP aren't really cutting it for communication. There are several bugs that haven't officially been acknowledged in the body of the thread that are now on the known issues list, and trying to keep tabs on everything in one big dirtball of a thread is just insane. It's got to be hard work for you, and it makes it really easy for users to miss responses on specific issues. There's off-the-shelf software for this stuff that is proven and used across the industry. The Dev server isn't working. People are playing with stuff as a preview, but they're not using it in anger so bugs aren't being found. I think you guys need to look at some sort of partial rollout approach. Believe me, I know how hard that is, but you're at a size now where it's a necessary step. Pro users - perhaps a specifically selected group - should be pushed onto a shard with a new version automatically, with an option to flip back if things aren't working. Expecting users  - particularly users who then have to explain it to their players - actively to select to be on a testing server for these kind of releases isn't realistic. A lot of the bugs with this release look like math bugs to me. Stephanie has already hinted that testing resources weren't really sufficient for a change of this magnitude, but from where I'm standing, a lot of these things shouldn't have got anywhere near QA - they're the type of stuff that should have been caught in automated unit testing written by the developer to prove formally that the system logic was correct. Of course, that does assume that said logic isn't inextricably intertwined with the actual browser canvas code.... Right? ;-) There seems to be a lot of process/technical debt showing through here. I guess you guys are under a lot of pressure to deliver features, but at some point you have get this stuff under control before it kills you. I've been there; it's not worth the pain :-/

Moving this here for GM Burrow: GM Burrow &nbsp;said: Since the new update, Fog of War does not seem to work as it once used to.&nbsp; When I reveal something to the players, but then want to hide it again, I use the&nbsp;"hide areas" button to drag a box over the area.&nbsp; Previously it would merge this with everything else.&nbsp; After the update it seems to draw multiple boxes over multiple layers.&nbsp; Like this: <a href="https://gyazo.com/8144a9bd405aeeb865e17518c3e9c1a1" rel="nofollow">https://gyazo.com/8144a9bd405aeeb865e17518c3e9c1a1</a> &nbsp; Which is annoying. I found other threads from over 10 months ago that was never resolved and auto closed due to inactivity.&nbsp; In that post, it mentioned a similar occurrence where that person couldn't&nbsp;find a thread prior that had a solution. Please fix

So I've done a little experimenting with the AFoW and the dynamic lighting issues with two of my players and have some results that may or may not be known already. 1. The primary issue that seems to arise with certain portions of the map being revealed even when the token has not traversed nor been in line of sight to the area seems to be connected to the "dim light reveals" function of the AFoW. With the setting on, and a token set to the standard 60, -5 darkvision setting, the problem seems to arise * whether the dynamic lighting wall is snap to grid or manually drawn* 2. Setting a non light emitting token to use a standard oh let's say 30 ft AFoW reveal, results in the same issue of certain squares being revealed that the token has not traversed or been in line of sight with yet. 3. A light emitting token with no dim light radius but instead all bright light and seems to work perfectly fine with both the dynamic lighting and AFoW but you must not utilize the dim light reveals feature. This would be fine except now your darkvision mechanics are incorrect with the light brightness. 4. Turning dim light reveals off and using the standard darkvision settings seems to work with both dynamic lighting and AFoW but the AFoW will only reveal * squares that the token has traversed over * not squares in it's sight range. If you were to add the AFoW sight distance onto this token, then it results in the same revealing past the dynamic lighting walls as before even though dim light reveals is turned off. So the conclusion I can draw is that the issue lies within the dim light reveals function and AFoW sight range settings. For DM's the best we can do until this gets fixed is use one if the two methods I described above that actually do work.

Hate to be a stick in the mud about a great update, but my Advanced Fog of War still runs at very very low FPS (&gt;20) on average. I'm using Firefox and my computer is really no slouch. Kinda disappointing because when I read this I was so excited to finally use it. Maybe I'm not using it correctly or something? It is just unplayable for me and my group because of the low FPS associated with it.

Moving this over for Startraphe. This is what Startraphe's players are seeing (screenshot below).&nbsp;AFoW/ dynamic lighting token issues when viewing:&nbsp; Startraphe;; T. &nbsp;said: My players are seeing the following: How do I fix this? Startraphe;; T. &nbsp;said: Sorry about that. Image I could have sworn I posted an image link. Weird.

Ancient Toaster said: Hate to be a stick in the mud about a great update, but my Advanced Fog of War still runs at very very low FPS (&gt;20) on average. I'm using Firefox and my computer is really no slouch. Kinda disappointing because when I read this I was so excited to finally use it. Maybe I'm not using it correctly or something? It is just unplayable for me and my group because of the low FPS associated with it. Agreed. The app is faster but still slow with AFoW. That being said I use a toaster.&nbsp;

so after the new lighting engine went live i have noticed that any token set on the map with a light or sight radius only has half the radius that its supposed to and that the dim light radius always shows 5 feet of dim light regardless of actual settings, i have tried all of the trouble shooting remedies posted in the troubleshooting forum and have not been able to resolve the problem. my current browser is firefox, but my players are using chrome and report the same issues on there end. i have been unable currently to attach a image of a screenshot of my issue so advice on another alternative would also be nice

kenneth f. said: so after the new lighting engine went live i have noticed that any token set on the map with a light or sight radius only has half the radius that its supposed to and that the dim light radius always shows 5 feet of dim light regardless of actual settings, i have tried all of the trouble shooting remedies posted in the troubleshooting forum and have not been able to resolve the problem. my current browser is firefox, but my players are using chrome and report the same issues on there end. i have been unable currently to attach a image of a screenshot of my issue so advice on another alternative would also be nice Yes seems to only happen on maps with grids that are not 1 Unit. For instance a 0.5 unit map.

Lucian said: I've been watching the progress of this thread with some interest. I have a few observations: I doubt a rollback is in anyone's interests right now. For an update of this complexity, I suspect that the consequences of rolling it back may end up being worse than fixing the bugs unless Roll20 have an insanely advanced deployment process. I get why people are asking but I honestly don't think it's going to help. In the long run, I really think you guys need a proper ticketing system (something tells me this will have been discussed). Stickied forum threads with a manually updated "known issues" list on the OP aren't really cutting it for communication. There are several bugs that haven't officially been acknowledged in the body of the thread that are now on the known issues list, and trying to keep tabs on everything in one big dirtball of a thread is just insane. It's got to be hard work for you, and it makes it really easy for users to miss responses on specific issues. There's off-the-shelf software for this stuff that is proven and used across the industry. The Dev server isn't working. People are playing with stuff as a preview, but they're not using it in anger so bugs aren't being found. I think you guys need to look at some sort of partial rollout approach. Believe me, I know how hard that is, but you're at a size now where it's a necessary step. Pro users - perhaps a specifically selected group - should be pushed onto a shard with a new version automatically, with an option to flip back if things aren't working. Expecting users&nbsp; - particularly users who then have to explain it to their players - actively to select to be on a testing server for these kind of releases isn't realistic. A lot of the bugs with this release look like math bugs to me. Stephanie has already hinted that testing resources weren't really sufficient for a change of this magnitude, but from where I'm standing, a lot of these things shouldn't have got anywhere near QA - they're the type of stuff that should have been caught in automated unit testing written by the developer to prove formally that the system logic was correct. Of course, that does assume that said logic isn't inextricably intertwined with the actual browser canvas code.... Right? ;-) There seems to be a lot of process/technical debt showing through here. I guess you guys are under a lot of pressure to deliver features, but at some point you have get this stuff under control before it kills you. I've been there; it's not worth the pain :-/ This is actually spot on and what I've been feeling. The person doing QA has another full time job, the bug reports are made via a forum post (by the way I've reported a very simple bug like a year or two ago which was acknowledged by staff and it's still unfixed lol), it all seems incredibly inefficient. It's like Roll20 outgrew the capabilities of its staff, but the management didn't hire more staff. Kinda weird.

охотник said: This is actually spot on and what I've been feeling. The person doing QA has another full time job, the bug reports are made via a forum post (by the way I've reported a very simple bug like a year or two ago which was acknowledged by staff and it's still unfixed lol), it all seems incredibly inefficient. It's like Roll20 outgrew the capabilities of its staff, but the management didn't hire more staff. Kinda weird. This stuff is hard; many, many companies fail at this point because handling rapid growth is incredibly challenging. Roll20 has hired a bunch of people in the last year, but one of the most effective ways to bring a software team to a grinding halt is to hire too many people at once - particularly if you rush it and hire the wrong people. But there's a whole bunch of other stuff that compounds the problem; in general, this rapid expansion phase is also one where there a lots of new opportunities and lots of excitement around moving the product forward; but it's also the time when you have to start going back and fixing all the technical debt you accumulated by lots of quick-and-dirty earlier development; and the time you have to start incorporating more rigorous and structured processes into everything you do (more people means more process). One of the classic mistakes here is to cave to the pressure to throw everything you have into product development and half-ass the refactoring/process improvements. At the heart of my comments above is the message to Roll20 that as far as this customer is concerned, I'd be very happy to see them take their foot off the pedal on the big feature developments and make the investment in getting their processes sorted and refactoring the hackier bits of their code. In the end it's actually faster anyway because you spend less time firefighting crises further down the line. But anyway, I guess we've drifted quite far off topic, so I'll stop there!

Stephanie B. said: Daniel H. said: I'm using advanced fog of war and dynamic lighting in a game im running, i can test run it with 1 player and it all run smoothly, the second all of us (7 in total) try and play the fog becomes completely unplayable, lagging terribly and even freezing and crashing completely sometimes requiring us to reload. That sounds pretty bad, Daniel. Can you reply with the game ID of the game you're playing so we can take a look and see if there's something causing that to happen? There's an odd error with image swapping that was reported earlier last week that we are trying to track down. <a href="https://app.roll20.net/join/3297583/QAHhaQ" rel="nofollow">https://app.roll20.net/join/3297583/QAHhaQ</a> Sure i've just turned the advanced fog of war back on in the game with the same settings i was using. Last weeks session i had to just turn it off as it wasn't working.

Can I just say that I really miss not having the overcharging and undercharging? With things like temporary HP and negative HP the old behavior was really amazingly useful.

Watching Adam Koebel wrestling with the light radius issue in Episode 17 of Roll20 presents: Dragon Heist (Youtube). Exactly the same as me, not knowing what was wrong but just dealing with it and moving on.

This seemingly started today with gif Animations for some reason during loop especially when the loop refreshes the image stutters for a split second. This also happens when you manually play an animation its as if a frame is out of place its pretty distracting and I've made sure its not the image I've tried with other images that were working just fine recently until now.

Will the request to return status bars to their original spots but implemented? Will the request to return auras to their original sizes (including negative numbers) be implemented? Please do this for us. As a long time user, I have used both of these to great effect for a long, long time. I would hate to see them go. Thank you!

Moving this over for&nbsp;DXWarlock: DXWarlock &nbsp;said: My players and me noticed this weekend any page with dynamic light set, turning it off doesn't disable it. Once you toggle dynamic lighting on, the only way I can get them to see the map is leave it on and to enable "global lighting". With it enabled: After I disable it (page still black):

DXWarlock &nbsp;said: My players and me noticed this weekend any page with dynamic light set, turning it off doesn't disable it. Once you toggle dynamic lighting on, the only way I can get them to see the map is leave it on and to enable "global lighting". I can confirm this. I ran into the same issue last night and came here to report it, but DXWarlock beat me to it!

Kirsty said: DXWarlock &nbsp;said: My players and me noticed this weekend any page with dynamic light set, turning it off doesn't disable it. Once you toggle dynamic lighting on, the only way I can get them to see the map is leave it on and to enable "global lighting". I can confirm this. I ran into the same issue last night and came here to report it, but DXWarlock beat me to it! Happened to me too this weekend, had to refresh the page to eliminate the dynamic lighting.

i am having a problem with my players tokens seeing all of their vision. Whatever i give them they only see half of it. I am using scripts but i have disabled them and than re-enabled one by one but none of them are the cause. I put a post up about it and they refverred to me here saying this is a known bug. any ideas how to fix would be amazing. Thanks for the help.

DXWarlock &nbsp;said: My players and me noticed this weekend any page with dynamic light set, turning it off doesn't disable it. Once you toggle dynamic lighting on, the only way I can get them to see the map is leave it on and to enable "global lighting". Kirsty said: I can confirm this. I ran into the same issue last night and came here to report it, but DXWarlock beat me to it! Ed S. said: Happened to me too this weekend, had to refresh the page to eliminate the dynamic lighting. As a quick hot fix, if you uncheck the box for Dynamic Lighting, Archive the page, and then Restore it from the Archive, Dynamic Lightning will no longer be on. Obviously this won't help much "in the moment" so to speak, if you're trying to reveal an entire page for your players, but it will make managing pages with dynamic lighting easier.

Dynamic Lightning and AFoW just went more crazy for me since yesterday. The players should just see with dim light, but when someone move his token, he can see EVERYTHING within a giant square. Dim Light Reveal is turned off. Left side: after dropping the token, Right side: after moving it.

I would also support a roll back. There have been no updates in February, and no ETA on a fix.&nbsp; Snow said: Given that's it's been just short of two weeks and there is still significant impact to core functionality; has it been considered rolling back this update on the production servers and taking another crack at it down the line on the test servers with the reported issues in mind? I think a rollback would give the development staff a chance to iron this update out without hampering&nbsp;the end users. While the animation bits are nifty and the claimed improvements to advanced lighting features would be a nice quality of life thing it doesn't seem worth the trade off of broken tokens and wonky grids/auras/bars. Reading Stephanie's posts here while well intended it still gives me the impression the the staff doesn't have the bandwidth to get the development work, quality assurance testing and customer support done all at the same time. Rolling back would give Development and QA time to work in private and save Customer support a lot of hassle. While the annoyance caused by this update are manageable I find it frustrating from the end user perspective to have to do extra work compensating and working around said issues. Having to say to my players 'sorry this looks wonky the platform has some issues right now' is also disheartening. My other concern is there are a fair number of folks with the pro and plus accounts that are paying for features that don't live up expectations / promotional material for close to half a billing cycle. While I imagine everyone at roll20 is well intended and working as hard as can be reasonable expected to get this going I still think it might be worth considering a rollback to restore core functions and take a second look at this update on the dev server. Thanks -Snow

Really hopping for some big hot fixes today, Tuesday seems to be the day the do the most of their rollouts. I do agree its been almost three weeks with no real fixes. Botley said: I would also support a roll back. There have been no updates in February, and no ETA on a fix.&nbsp; Snow said: Given that's it's been just short of two weeks and there is still significant impact to core functionality; has it been considered rolling back this update on the production servers and taking another crack at it down the line on the test servers with the reported issues in mind? I think a rollback would give the development staff a chance to iron this update out without hampering&nbsp;the end users. While the animation bits are nifty and the claimed improvements to advanced lighting features would be a nice quality of life thing it doesn't seem worth the trade off of broken tokens and wonky grids/auras/bars. Reading Stephanie's posts here while well intended it still gives me the impression the the staff doesn't have the bandwidth to get the development work, quality assurance testing and customer support done all at the same time. Rolling back would give Development and QA time to work in private and save Customer support a lot of hassle. While the annoyance caused by this update are manageable I find it frustrating from the end user perspective to have to do extra work compensating and working around said issues. Having to say to my players 'sorry this looks wonky the platform has some issues right now' is also disheartening. My other concern is there are a fair number of folks with the pro and plus accounts that are paying for features that don't live up expectations / promotional material for close to half a billing cycle. While I imagine everyone at roll20 is well intended and working as hard as can be reasonable expected to get this going I still think it might be worth considering a rollback to restore core functions and take a second look at this update on the dev server. Thanks -Snow

Did these issues get any update at all today? No fixes are listed as far as I can tell.

They did not. We have fixes for some of the issues, but they didn't get into this morning's push. We're planning a hotfix later this week that will include them.

Anthony V. &nbsp;said: Really hopping for some big hot fixes today, Tuesday seems to be the day the do the most of their rollouts. I do agree its been almost three weeks with no real fixes. Last Hotfix was January 31. Today is Feb 12. That's not even two weeks. I know we all want it soon (I do, too, believe me), but I'd rather have a fix that takes longer and really fixes, not something that is pushed too quickly and introduces more problems.

Agreed, Keith. Also, I don't know how resources are split, but with the Fanburst issues I could well imagine that dev attention is split into that emergency situation as well. I want this stuff fixed too, but also would rather have it fixed correctly than rushed and buggy. keithcurtis said: Last Hotfix was January 31. Today is Feb 12. That's not even two weeks. I know we all want it soon (I do, too, believe me), but I'd rather have a fix that takes longer and really fixes, not something that is pushed too quickly and introduces more problems.

I'm guessing that there was also a huge backlog of fixes on the Dungeon of the Mad Mage, since that went out today.

I know this thread is about feedback on advanced fog of war and animations, but the bug report thread I started was closed by a moderator who told me this thread was the correct location to post these issues, so here goes: Edit: upon reading the rest of this thread looking for mentions of my issues, I noticed that most people posting here about dynamic lighting are also using AFoW. I am not. I use dynamic lighting only, with 'restrict movement', 'update on drop only', and 'enforce line of sight' options checked on most maps. I use a square grid, standard multiplier with 5 foot squares. I sometimes suppliment this with old style fog of war, in order to conceal things manually that dynamic lighting doesn't conceal automatically, but the tests I performed to get the numbers mentioned in the bugs were done without fog of war enabled. These bugs are occuring in multiple games for me. Bugs: First bug is the range doesn't work. If I want a token to have sight for 60 feet, I need to set its sight range to 80. If I want 120 feet, I need to set it to 170. Second bug is there is an automatic dimness applied to some range in the sight. This can be worked around by setting the 'dim' light number to what the sight range number is, but it isn't how it is supposed to work according to the tooltips. Third bug is some of my players are getting vision from tokens that are not assigned to them. This has no workaround as far as I can tell. Issues: "Walls" come up black, but so does darkness. As it is it is hard to tell the difference while it would be obvious to the character. If we could assign a texture or even have walls come up in the color of the line that is drawn, it would be a big improvement - as what is visible and what is not would be much more clear. D&amp;D 5e only issue: Darkvision rules turn dim light into bright light, and darkness into dim light, up to a certain range. It would be nice to be able to set 'darkvision' as most characters have access to it. The current token settings allow us to create dim light out to a radius but it fades out to black way too early and starts way too clear. It also doesn't turn into bright light if there is dim light available. As far as I can tell there is no way to make 5e darkvision work with the current dynamic lighting system. Thanks for looking at this!

You're in the right place Max. This particular update caused a lot of dynamic lighting issues. Some of the ones your report are in the top post.

Faeriedae said: Faeriedae said: Hey so every since the most recent update trying to use AFOW completely lags me and my players games. We all have computers capable of running modern video games so this is pretty confusing. It might just be because the maps were playing on are too large however we played on the same maps without a problem before the update. Would love to know if there's any way to fix it. Edit: Ok, I know CTRL+L being busted is mentioned in the known bugs but i've just realized it seems sometimes when I switch between maps the blotted out parts of the previous map seem to show up when I use CTRL+L. So that's weird. Edit 2: Ok so I think my game is just completely broken because I've set a map to have dynamic lighting and no global illumination yet when I join as a player with a token that shouldn't be able to see anything I can still see pretty much everything except a small portion of the map that AFOW is kind of working on. I uploaded some videos of some the issues: <a href="https://youtu.be/jQItTV7IalU" rel="nofollow">https://youtu.be/jQItTV7IalU</a> <a href="https://youtu.be/WxDBKMA7S8c" rel="nofollow">https://youtu.be/WxDBKMA7S8c</a> I'd really appreciate some help. Well about a week since my original post and not much has changed however I've done some testing and figured out that the lag we experience is directly tied to the AFOW view distance(Or Light Emitted if there is no view distance.) . About anything 15 inches or higher is pretty much unplayable. I've also uploaded a video of this issue:&nbsp; <a href="https://www.youtube.com/watch?v=otw9oQbCR8Y" rel="nofollow">https://www.youtube.com/watch?v=otw9oQbCR8Y</a> &nbsp; Some help or insight would be greatly appreciated.&nbsp;

Hi, folks! We included a couple of bug fixes this morning when we pushed the hotfix for My Audio. Items on map layer no longer show token bars The play/pause button on animated tokens no longer covers the status icons. We're still working on the rest of the issues; the token bar issues are at the top of the list, and will likely go out in next week's scheduled patch. We tried to get them out today, but they didn't quite pass QA. Thanks for your patience! The Known Issues list at the top of this thread has been updated.

I didnt see anyone mentioning this specific issue, though i think it was in the known issues, but when using dynamic lighting with a sight range less than 360 degrees, the actual character token itself becomes obscured by the darkness as opposed to sitting on top of it like it used to.&nbsp; Eg. What the GM sees.&nbsp; <a href="https://i.gyazo.com/f0edbe05e4f7227a7b506b5e46532d53.png" rel="nofollow">https://i.gyazo.com/f0edbe05e4f7227a7b506b5e46532d53.png</a> What the player sees.&nbsp; <a href="https://i.gyazo.com/6c842dfb382764580346369379035757.png" rel="nofollow">https://i.gyazo.com/6c842dfb382764580346369379035757.png</a> With even the nameplate concealed this issue makes it very difficult for players to identify their tokens among others. Additionally on a lesser note, the smaller sub-icons (The dropdown menu with all the colored dots?) Now rotate with the character token, which makes it harder to keep track of the values recorded.

Hi, Kyle, That's in the Known Issues list at the top of the thread. The status icon rotation is also known, and we'll be considering the best way to handle that (it's a side effect of fixing something that was broken before). kyle t. said: I didnt see anyone mentioning this specific issue, though i think it was in the known issues, but when using dynamic lighting with a sight range less than 360 degrees, the actual character token itself becomes obscured by the darkness as opposed to sitting on top of it like it used to.&nbsp;

This is my experience with the lighting, which may relate to the AfoW issues: The dynamic lighting does not extend past the primary light range. Dim light doesn't extend view range. The primary light range provides visually dim light. If I set the dim light range to overlap with the primary light range, they combine to provide bright light. If I set the dim light range to extend past the primary light range, I don't gain any light past the primary light radius. However, if I set the primary light range further than the dim light range, the primary light outside the dim light radius provides visually dim light, with the dim light overlapping with the primary light creates a smaller pool of bright light. It's almost like the primary light and dim light range boxes have switched places, but that doesn't seem to be the case. After all, I could use either light range independently before and get the appropriate light, whereas I now have to overlap the two to get bright light. While the dynamic lighting provides vision in a circle, the revealed area of the AfoW is always perfectly square. Also, "dim light reveals" appears to reveal a huge area *when turned off*.

I think you're looking at it backwards. 60/30 means you get 60 total feet of light, and the dim light starts at 30. Dim light is not added onto the end of bright; it's not an extension. This is why 30/30 or 30/60 wouldn't change anything you are seeing.

Thanks for the vote of confidence, KeithCurtis, but the top post does not yet contain the bugs I mentioned as far as I can see, and the only mention in the thread of any of these issues I could find was similar but not exactly like my second bug where dim light is 'automatically enforced' and 'not matching the setting'. I would like to be sure that my bug reports are reaching the dev team, or someone with access to their issue tracker or whatever. You have that fancy 'forum champion' badge - does that mean you work for roll20 and I can consider the mail delivered? Or does it just mean the forum interposed you between themselves and a challenging duelist at some point?

Neither one, and I hope the post wasn't received as antagonistic. It seemed you had a misunderstanding of the settings, but it's entirely possible I simply misunderstood your statement of the problem. In any case, in an official thread (as this one is labeled), someone from the dev team is managing it (in this case, Stephanie B.). Mods and forum champions may chime in to offer help or (in the former case) to copy over a post from another thread. But ultimately, if you post it here, a dev sees it. I'm still not understanding what you are stating as a bug. I'm willing to help, but if you'd prefer to let a dev handle it, I'll step aside.

No I didn't think you were being antagonistic at all - you came across as friendly, KeithCurtis. I appreciate your offer to help, but I am sure there is at least one bug at play here, and after spending a few hours doing free testing for a company I don't work for but am rather a client of, I feel like listing my bugs in "known problems" or allowing me to start a thread about them in the forums, or even a dev telling me I'm full of shit (but they took the time to read my post) would be nice. I edited my post to reiterate the fact that I did not have AFoW enabled in the game I used to test these bugs. I have recreated these bugs in two separate games. The bugs I mentioned in the previous post are under the heading "bugs".&nbsp; I suppose I numbered them with words instead of numerals, which is kind of offputting when I reread them, but I don't know what exactly you misinterpreted. I'll reword/elaborate. The following bugs are recreated with dynamic lighting enabled but AFoW disabled. Regulare FoW is also disabled. The number fields in the token settings under "Emits light" are not individually labeled, but when not using AFoW and only using Dynamic lighting, the "Emits Light" settings are used, and there is one box for "sight range" and another for "start of dim light" (if I refer to numbers before and after a "/" character, they are these, respectively). I believe that old functionality and/or a tooltip or instruction somewhere led me to believe that leaving the "start of dim light" field blank would result in dim light not starting. 1) Dynamic Lighting light ranges are incorrect. Set a token to 60/60 (60 sight range, 60 start of dim light) on a map with grid size 1, 5 feet per square, measurement style "D&amp;D 5e/4e". You will get a token with vision out to 45 feet.&nbsp; To get the range to 60, I had to set tokens to 80/80, and to get 120 feet of vision, I needed to set it to 170/170 (the expected 160/160 didn't reach). Note that the vision circle did not match the expected result on the measuring tool. I counted squares to make sure the measuring tool was functioning. 2) Leaving the dim light field blank doesn't work. It must be set to the same setting as the sight range if you don't want a random fade to black in the middle of your token's vision. *divergence from original post: when I attempted to test different settings of 'start of dim light' I found that in one of the two games I was using to test, the sight range distances suddenly started being correct&nbsp; - matching the value from the measuring tool.&nbsp; Leaving 'start of dim' blank still resulted in about a third of the tokens vision being obscured by dim light. I don't know exactly how to recreate this either, but it happened while I was adjusting 'start of dim' values between 170 and 120, I believe. In the other game the bug continues, I double checked after one environment started working correctly all of a sudden. 3) Some of the players in one game I run have reported having vision from tokens that are not theirs, nor representing characters assigned to them. I don't know a workaround for this or a way to recreate.

Moving this over for&nbsp;Kimitsu D.: Kimitsu D. &nbsp;said: Hello. It seems that around the time animated gif support was added, a new bug was introduced: if you don't use grids on your maps, the auras are no longer displayed properly. Their size seems to get capped by the size of the token. Could be due to the scaling factor defaulting to 0, or something. Truly hope this gets fixed.

Max: My fault entirely, actually. I did not read carefully enough and thought your post was from a different user, the one I was working with on Dynamic Lighting values. Ignore the last sentence about "not understanding what you are reporting as a bug". My initial response to you was mostly to let you know you were reporting your bugs in the right place. My second response to you was misdirected. Sorry for the confusion. :) The other stuff I said was still factually accurate, in that mods and forum champions can help users with bugs, or even report them, but the official tracking of them and monitoring them within an official thread is dev territory. Stephanie will be the one to collate reports, update the list and so on.&nbsp;

Max said: No I didn't think you were being antagonistic at all - you came across as friendly, KeithCurtis. I appreciate your offer to help, but I am sure there is at least one bug at play here, and after spending a few hours doing free testing for a company I don't work for but am rather a client of, I feel like listing my bugs in "known problems" or allowing me to start a thread about them in the forums, or even a dev telling me I'm full of shit (but they took the time to read my post) would be nice. I edited my post to reiterate the fact that I did not have AFoW enabled in the game I used to test these bugs. I have recreated these bugs in two separate games. Hi, Max, Thanks for your reports. As you can imagine, yesterday was a very busy day here at Roll20, and I was less able to respond to this thread. Your posts are definitely being read and brought to the devs' attention. I read *every* post here. As mentioned last week, I update the Known Issues after I can re-create the issue, and I can't always respond to every post in the thread. If I haven't asked questions to follow-up, or it's not in the Known Issues list, it's either because I haven't had time to research and reproduce the issue, or it's in the Known Issues but phrased in a way that isn't clearly the same as the bug being reported. For example, a number of people have reported an issue with full/dim lighting that is related to the grid scaling being a .5 rather than 1, but if someone reports the same behavior but didn't realize their grid is at .5, they're reporting the same issue and may not realize it. The information you've provided will be very helpful in troubleshooting these issues, and I appreciate it. Can you please provide the game IDs (it's the number in the URL when you go to your campaign page, before clicking "Launch Game")? Sometimes, I am better able to reproduce a problem if I can look directly at all the factors going into *your* specific game or, in this case, games. In some cases, the issue is not reproducible. For these, the Solving Technical Issues wiki page usually helps, or there's sometimes a game corruption issue that may be causing the problem. Understand: that's not &nbsp;the case here-- I definitely believe you are able to reproduce the issue reliably, and the behavior you describe has been reported by other users in the thread. It's just a matter of my own in-depth troubleshooting on my side to reliably recreate the issue and describe it properly for the KIs list.

Is there by any chance an update on the AFoW leaking through corners issue? I feel like there have been multiple examples of how to reproduce as well as work arounds that should shed light on what's going on under the hood. I'm just worried that if we don't hear anything today, we go into the weekend (you guys don't push on weekends, I can respect that, I wish my company didn't), which means we roll into yet another week of one of the title features of this update being unusable, and people buying official modules getting broken content.

We're working on it, Rob. It's in front of a dev right now, and I believe it's next after he finishes fixing the token bar issues (it has the same priority as the .5 bug, so I'm not 100% sure which one he's tackling first). Unfortunately, it will not go out before the weekend. Rob W. said: Is there by any chance an update on the AFoW leaking through corners issue?&nbsp;

Faeriedae said: Faeriedae said: Faeriedae said: Hey so every since the most recent update trying to use AFOW completely lags me and my players games. We all have computers capable of running modern video games so this is pretty confusing. It might just be because the maps were playing on are too large however we played on the same maps without a problem before the update. Would love to know if there's any way to fix it. Edit: Ok, I know CTRL+L being busted is mentioned in the known bugs but i've just realized it seems sometimes when I switch between maps the blotted out parts of the previous map seem to show up when I use CTRL+L. So that's weird. Edit 2: Ok so I think my game is just completely broken because I've set a map to have dynamic lighting and no global illumination yet when I join as a player with a token that shouldn't be able to see anything I can still see pretty much everything except a small portion of the map that AFOW is kind of working on. I uploaded some videos of some the issues: <a href="https://youtu.be/jQItTV7IalU" rel="nofollow">https://youtu.be/jQItTV7IalU</a> <a href="https://youtu.be/WxDBKMA7S8c" rel="nofollow">https://youtu.be/WxDBKMA7S8c</a> I'd really appreciate some help. Well about a week since my original post and not much has changed however I've done some testing and figured out that the lag we experience is directly tied to the AFOW view distance(Or Light Emitted if there is no view distance.) . About anything 15 inches or higher is pretty much unplayable. I've also uploaded a video of this issue:&nbsp; <a href="https://www.youtube.com/watch?v=otw9oQbCR8Y" rel="nofollow">https://www.youtube.com/watch?v=otw9oQbCR8Y</a> &nbsp; Some help or insight would be greatly appreciated.&nbsp; Please.

Stephanie B. said: We're working on it, Rob. It's in front of a dev right now, and I believe it's next after he finishes fixing the token bar issues (it has the same priority as the .5 bug, so I'm not 100% sure which one he's tackling first). Unfortunately, it will not go out before the weekend. Thank you

Moving this for Dylan G: Dylan G. &nbsp;said: Uploading animated files causes the upload bar to hang. Reloading shows previews of the uploaded file, but it cannot be dragged to the tabletop and shows a blank preview when added to a handout. I have attempted this on both Firefox and Chrome using multiple networks with both .webm and .mp4 files. LOGS Chrome on upload:&nbsp; DROP ON FILE UPLOAD app.js?1550165007:554 uploadstarted EVENT app.js?1550165007:544 Is Video; sizeArray: (3) [Array(3), Array(3), Array(3)] app.js?1550165007:544 Reader load! app.js?1550165007:544 Uploading a size: 100x100 app.js?1550165007:544 Uploading a size: 200x200 Then it hangs. Firefox on upload: DROP ON FILE UPLOAD app.js :544:27293 uploadstarted EVENT app.js :554:16846 Is Video; sizeArray: Array (3) [ (3) [ … ] , (3) [ … ] , (3) [ … ] ] app.js :544:20709 Reader load! app.js :544:20983 Successfully compiled asm.js code (loaded from cache in 82ms) ffmpeg-worker-webm.2.js Uploading a size: 100x100 app.js :544:21238 Successfully compiled asm.js code (loaded from cache in 80ms) ffmpeg-worker-webm.2.js Uploading a size: 200x200 app.js :544:21238 XML Parsing Error: no root element found Location: <a href="https://s3.amazonaws.com/files.d20.io/images/73951882/bRLNIHA41r9sY9I_0dKWKA/sample.png?AWSAccessKeyId=AKIAIVMOBMWG4CULMUMQ&amp;Expires=1550209597&amp;Signature=%2Fw9jOW2rVMxRZll3UvyqYkmdOrI%3D" rel="nofollow">https://s3.amazonaws.com/files.d20.io/images/73951882/bRLNIHA41r9sY9I_0dKWKA/sample.png?AWSAccessKeyId=AKIAIVMOBMWG4CULMUMQ&amp;Expires=1550209597&amp;Signature=%2Fw9jOW2rVMxRZll3UvyqYkmdOrI%3D</a> Line Number 1, Column 1: sample.png :1:1 Successfully compiled asm.js code (loaded from cache in 82ms) ffmpeg-worker-webm.2.js Chrome on reload: GET <a href="https://s3.amazonaws.com/files.d20.io/images/73951307/UoOV3g7Grx945Qv2R12bJQ/thumb.webm?1550205317" rel="nofollow">https://s3.amazonaws.com/files.d20.io/images/73951307/UoOV3g7Grx945Qv2R12bJQ/thumb.webm?1550205317</a> 403 (Forbidden) Firefox on reload: HTTP load failed with status 403. Load of media resource <a href="https://s3.amazonaws.com/files.d20.io/images/73950758/7s3ZMx3YNNi7in5q3dde5A/med.webm?1550204675" rel="nofollow">https://s3.amazonaws.com/files.d20.io/images/73950758/7s3ZMx3YNNi7in5q3dde5A/med.webm?1550204675</a> failed.