Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account
This post has been closed. You can still view previous posts, but you can't post any new replies.

A New Light - Bug Thread - Updated Dynamic Lighting and Fog of War

Hi Jarl Khan -  We have been trying to recreate the issue you mentioned here , but have been unable to so far. To confirm, are you still experiencing the problem? If so, is it still in the same game? Or is it in another game using the Legacy system? 
Hey folks -  In regards to Marketplace questions, to clarify, we will absolutely make certain that Marketplace products work seamlessly with the new system. Further details will come later down the road. Thanks for checking in on this! :) 
Perfect setup :) They seem to be rolling out updates around every wednesday, so a new test like this every thurday, would just be perfect. I too look forward to the day that i can convert to the new system. one of the main issues is performance/lagging. You have a way of testing this?  At the moment, I'm not worried about Performance/Lag. When doing any kind of program development, you make the features, and then you make the system efficient afterwards. We're not out of Alpha, yet. That being said, I do have a Performance Smoke Test, and here is my plan for once the major issues with UDL is updated. My plan is to execute two types of performance tests from two perspectives, GM and Player. The Performance will use the Google Performance Monitor to monitor length of time <5fps, and ==0fps. It will also monitor ticks for me. The following tests are planned for me to execute: Move Non-Sighted, Non-Light Token 1 Cell from {not visible to not visible, not visible to visible, visible to not visible, visible to visible} Move Non-Sighted, Light Token 1 Cell {in sight visibility of a Sighted Token, not in sight visibility of a Sighted Token} Move Sighted, Non-Light Token 1 Cell Move Sighted, Light Token 1 Cell The plan is to setup the following three environments: Base Roll20 Setup with Advanced Fog of War + Legacy Dynamic Lighting in my normal setup. Modified Roll20 Setup with Advanced Fog of War + Legacy Dynamic Lighting. New Roll20 Setup with New Dynamic Lighting. The modified Roll20 Setup I will be replacing the Javascript files with the Google Chrome JS Replace in dev tools. As mentioned before, I found that _.clone was just causing an issue with performance and removing that one method call in the tests allowed for an 80% increase in performance. Once we get down to that there are only minor issues, I'll start doing Performance Comparison tests. For right now, I think that its not worth it as the code is changing a lot.
Hey all -  For those experiencing issues with Update Dynamic Lighting (UDL) on Safari, just to confirm, the only browsers Roll20 supports are Chrome and Firefox. Using unsupported browsers, such as Safari, may result in certain features and functions not working, including those associated with UDL. 
What you were trying to do:  Moved a token out of his earlier viewing-area with STRG+L as GM. Player told me, he has the same vision. What happened: First u see a sharp wall on the right side. If the players leave the area, the wall isnt sharp anymore. Steps to Reproduce: self-explaining Browser & OS info: Windows 10 64 Bit, Google chrome Is WebGL supported by your browser? Game Link:  not needed I think. Game Settings: No special settings Map Settings: Legacy, Explorer mode, no daylight mode. Token Settings: regular vision, no light emitted. Do you have Hardware Acceleration turned On or Off in your browser or system: on
1588295076

Edited 1588295176
Zachare S. said: At the moment, I'm not worried about Performance/Lag. When doing any kind of program development, you make the features, and then you make the system efficient afterwards. We're not out of Alpha, yet. I mean, yes, but also tell that all the people in this thread and watching these developments who are having major use issues even without the UDL turned on in their games. Also, this isn't exactly some free program in development. This is a paid feature, for a website that is several years old at this point. Roll20 as a company isn't some plucky lil' start-up out of two guys apartment anymore and shouldn't be treated as such.
1588301340

Edited 1588301380
On April the 29th our game also experienced difficulties with dynamic lighting, as described by Justin. At random times one or other player would be able to see the whole map, secret doors and everything. When they moved their token it would all go back to normal. I have checked all the settings on each token and the page are as described by the dynamic lighting instructions. This was our second session using dynamic lighting, the first was on April 26th and went fine. I moved to the "plus" subscription specifically  to use dynamic lighting and it ruined our session! I'm really hoping this can be resolved. Justin N. said: ... The worst issue is when for some reason everything is going good and then all of a sudden the player will be able to see the entire map (inside solid stone, like everything...) but it will be in black and white (or gray scale) like you have with the fog of war or in (Explorer mode?) when the player has already seen something.  But they could not have seen the entire map inside walls, etc. like I see as the GM.  I've fought with this issue for at least 40 hours trying to figure out what causes this.  At first I thought it was due to me having access to the characters to move them around (I had my name assigned to each of the characters and NPCs because I thought I needed this to manipulate or modify them... but I guess as GM I do not).  It also happened once instantaneously in real time when I clicked onto a player's token and hit ctrl-L to "see" what she was seeing at that moment and the instant I did this the player said "Whoa!  I can see the entire map... like everything inside solid rock and walls and the legend and all the monsters and lamps and chests and even the monsters you have stuck in the solid rock to pull out to use in Random Encounters.  
Nicholas said: Hey folks -  In regards to Marketplace questions, to clarify, we will absolutely make certain that Marketplace products work seamlessly with the new system. Further details will come later down the road. Thanks for checking in on this! :)  Hi, I'd settle for the Marketplace Products working seamlessly with the old system, like the case was a few weeks ago.
GM moving a NPC token leads to map being "explored" by some players What you were trying to do: Moved a NPC token as GM What happened: &nbsp;(Screen shots are useful here!) 2 of my players reported that suddenly they saw the whole map, including areas that should be completely inaccessible due to dynamic lighting barriers, in a greyed out form, as if they had explored everything. The 3 other players didn't have that problem. Steps to Reproduce: Happened on two different maps. Browser &amp; OS info: Chrome, Windows 10 Is WebGL supported by your browser? Please visit&nbsp; <a href="https://webglreport.com/" rel="nofollow">https://webglreport.com/</a> &nbsp;and copy/paste the WebGL1 report from there. Game Link: &nbsp;(The URL when you're looking at your Game Details page) <a href="https://app.roll20.net/campaigns/details/6475335/essentials-kit" rel="nofollow">https://app.roll20.net/campaigns/details/6475335/essentials-kit</a> Game Settings Was anything changed from default? Yes Map Settings Are you using Legacy or Updated? Updated Were you using Explorer Mode or not? Yes Were you using Daylight Mode or not? No Token Settings What kinds of light and vision were utilized on tokens? (bright light, low light, night vision, regular vision) Vision, night vision, bright light and low light all on
This is my first time using the dynamic lighting function, and I had all sorts of issue from my players perspective. For one player, they were completely unable to see anything and moving their token was very delayed. For another, they lost vision of all light on the map except for a token that emitted light. And for the other 2 things went smoothly. Exact same settings for all players. Some notes I put the majority of my lighting "objects" on the dynamic lighting layer. Don't know if that's a no-no. At times, I could drop all the players on a previous map and bring them back in and it would fix the issue. I had the grid turned off. Sort of disappointed because I put a lot of work into setting it up and figuring it out only to now feel like I should abandon it all together...&nbsp;
Steven said: Hi, so we're also having trouble with the OLD AFOW since this week. Last week on wednesday everything was working as expected with DL and AFOW. But as we played our game this week on wednesday my players noticed that line of sight / DL works as expected, but newly discovered areas are hidden again once characters leave, while areas discovered last week are still visible (in b/w). Could this be due to this update? Confirming that this issue has also cropped up for me. Game created from scratch using old systems, Legacy DL and AFOW, three players, all with identical token settings. For two of the three, everything worked as expected with greyed-out view of areas previously explored, but for the third player anything not immediately in view was showing as solid black. Not occuring on my end so unable to provide full details, but from my understanding this was on a laptop running Chrome on Win10, which in previous sessions has worked fine.
Zachare S. said: Perfect setup :) They seem to be rolling out updates around every wednesday, so a new test like this every thurday, would just be perfect. I too look forward to the day that i can convert to the new system. one of the main issues is performance/lagging. You have a way of testing this?&nbsp; At the moment, I'm not worried about Performance/Lag. When doing any kind of program development, you make the features, and then you make the system efficient afterwards. We're not out of Alpha, yet. That being said, I do have a Performance Smoke Test, and here is my plan for once the major issues with UDL is updated. My plan is to execute two types of performance tests from two perspectives, GM and Player. The Performance will use the Google Performance Monitor to monitor length of time &lt;5fps, and ==0fps. It will also monitor ticks for me. The following tests are planned for me to execute: Move Non-Sighted, Non-Light Token 1 Cell from {not visible to not visible, not visible to visible, visible to not visible, visible to visible} Move Non-Sighted, Light Token 1 Cell {in sight visibility of a Sighted Token, not in sight visibility of a Sighted Token} Move Sighted, Non-Light Token 1 Cell Move Sighted, Light Token 1 Cell The plan is to setup the following three environments: Base Roll20 Setup with Advanced Fog of War + Legacy Dynamic Lighting in my normal setup. Modified Roll20 Setup with Advanced Fog of War + Legacy Dynamic Lighting. New Roll20 Setup with New Dynamic Lighting. The modified Roll20 Setup I will be replacing the Javascript files with the Google Chrome JS Replace in dev tools. As mentioned before, I found that _.clone was just causing an issue with performance and removing that one method call in the tests allowed for an 80% increase in performance. Once we get down to that there are only minor issues, I'll start doing Performance Comparison tests. For right now, I think that its not worth it as the code is changing a lot. Just wanted to mention, you are doing fantastic work with these posts. Being a developer myself, I understand everything you are doing, you've basically become the QA for this functionality. I only hope they are listening to your advice and determinations so that this can be a viable and efficient fucntionality. I was thinking of doing this myself, but it's just excellent the work you've done and posted here. Thank you, I find this information far more valuable than the sporadic updates on the change notes. I find myself looking forward to your posts and subsequent evaluations, keep up the good work.
1588362778

Edited 1588362937
Tokens can see through the barrier . Not sure if this is currently being addressed, but this is the main issue that isn't allowing me to use the feature.&nbsp;
Hey folks - We pushed out a fix for an issue this week where the functionality of CTRL+L could be "reversed" - i.e. you click on the token and it does nothing, you click off the token and it performs CTRL-L functionality. If you notice further problems with this particular issue, please let us know. Thanks!
1588371051

Edited 1588371069
Nicholas
Roll20 Team
Hey everyone -&nbsp; As some of you pointed out [ 1 ], there was a weird issue going on where Tokens on different pages were revealing masks for the incorrect page. However, we pushed out a fix for it this week, and it should be good to go. Please let us know if you run into any further problems with it.&nbsp;
Hi there - A fix has been pushed out this week for a reported problem &nbsp;with how fractional numbers were calculated with Vision/Lighting. Please let us know if you notice and other problems or issues related to it. Thank you! :)
New to using dynamic lighting, but I"m having similar issues with two players out of 8 between two campaigns. Both players appear to have trouble when moving between tabs going from roll20 back to something like dndbeyond and back to roll20. When they come back in, they both can see the entire map, no mask or fog of war which of course causes big problems. For now I"m having them not switch tabs and when they do switch they need to move their characters again to get it to redraw the lighting and correct itself (this corrects the issue for one character). For the other character I as the DM needed to replace a door or make another light shift of some sort to correct the issue and then the light corrected itself as his movement did not correct the issue (even moving a line in the dynamic layer that is nowhere near his vision worked to correct the issue on his end). So this issue seems to be caused by leaving and returning to the roll20 tab as best as I can tell for now.&nbsp; If more details from the players will help let me know please, but the former is on a mac on chrome and the latter is on windows chrome.
1588397773

Edited 1588397831
Just ran my game tonight, and I ran into the same issue with my players as Joe N had. They use firefox &amp; chrome, and would switch tabs to look at something else and when switch back they could see the whole map. I at first last weekend thought it was explorer mode, but i turned that off for this new map and they still had the same issue. So I had them pop out the Roll20 Tab and not switch away from it by putting it in it's own window. The problem still persisted as when they moved their tokens or if i deleted any tokens they could get a glimpse of the map, but when they moved again the darkness would reappear. It was very unreliable and a bit of a let down as they were able to see my whole dungeon map, secret rooms and all.
I bought premium for Dynamic Light feature, because my campain is going underground at the moment. I thought it would be cool and perfect time to test it. This is short report how we liked it. It's dissapoiting. It's like you didn't even check if this works after you make it.&nbsp; So I spend those 5$ and 3h making a dungeon with that Updated Light. Then we played a 5h fight there with 4 people. Believe me or not, after 2 hours I had enough and I turn that Lightning off and just hide map with Fog of War. ALL PLAYER HAD PROBLEMS. NONE OF THEM WAS SEEING THE RIGHT THING ALL THE TIME. How is that possible after a month in Beta that none of this works? I had problems - almost every time I moved token that had something to do with light I've heard "Oh, GM, I don't see anything now...". So we moved tokens, light or something so he get his vision back. And you know what? When it fixed I've heard a lot of times another person "Oh, I don't see this guy anymore, GM". There were reloading page because that's what usually worked for them fastest, but not always. There was 7 poeple total watching this and none of then want it again, me included. None of then had any GOOD word about what there saw except "it's a nice idea I guess. But maybe leave it for, like, half a year, maybe then?". And that was exacly my feeling, too. It was my first attempt to Dynamic Light. It was my last attempt to Dynamic Light. I would rather make my life hard and use Fog of War, which actually works great. With few additionsfrom your side it could easy do the same job, better. Probably not going to happed. Shame I had to pay 5$ to understand that. Anyway - thanks for trying make Roll20 better.
Nicholas said: Hey folks - We pushed out a fix for an issue this week where the functionality of CTRL+L could be "reversed" - i.e. you click on the token and it does nothing, you click off the token and it performs CTRL-L functionality. If you notice further problems with this particular issue, please let us know. Thanks! I'm running into a problem, where CTRL+L selects the URL bar, that's standard for Windows, but I'm wondering if there is a Windows setting that I need to disable to make this function work for me.&nbsp; Chrome Version 81.0.4044.129 (Official Build) (64-bit), Windows 10.
Richard, I don't have a problem with Ctrl+L as that functionality doesn't work for me when in Roll20. When I hit Ctrl+L with or without a token selected in Roll20 it does not jump to the address bar. However doing so outside of Roll20 does jump to and select the address bar as does pressing F6. However pressing F6 does jump to and highlight/select the URL as it would on any other page. However, looking back now on posts a few other folks are also reporting something similar, so this may be some kind of localized bug only impacting certain people or scenarios. One person did suggest to make sure that the map in question did have Dynamic Lighting enabled or the Ctrl+L function would work as per normal for the browser and jump to the URL. I was able to replicate this by flipping between a few different pages in the prebuilt Dungeon of the Mad Mage and for maps with old or new dynamic lighting enabled the Ctrl+L functionality to jump to URL is suppressed. When using it in a map without enabled lighting it jumped to the browser address bar though. This was independent of whether or not there was anything on the dynamic lighting layer however. Hopefully this helps, but if you still have this behavior you may be seeing a bug that needs pursuing in your individual case. Joe
1588425636

Edited 1588425677
Joe N. said: One person did suggest to make sure that the map in question did have Dynamic Lighting enabled or the Ctrl+L function would work as per normal for the browser and jump to the URL.&nbsp; Hi Joe, thanks for your helpful response.&nbsp; This is indeed correct!&nbsp; I wanted to test fog of war, and I needed to enable Dynamic Lighting to do so.
1588432238

Edited 1588432342
There is still a glitch where my players can see what they’re &nbsp;not supposed to see if they’re to close to a wall or something. &nbsp;Like they can see through everything randomly until they wiggle their token. &nbsp;On character had night vision plus emotes 10ft of dim light cause of an item. &nbsp;Every time he was near a wall he could see everything. &nbsp;Had to switch back to old way. &nbsp;Don’t know if it matters. But I’m using google chrome on a mac.
1588435543

Edited 1588435851
This new system is terrible. Absolutely terrible. What you were trying to do: I was just trying to add a token to the map What happened: The moment I added a new token, the dynamic lighting just stopped working completely and the entire map was illuminated. Steps to Reproduce: How the heck should I know Browser &amp; OS info: Firefox, Windows 10 Is WebGL supported by your browser? Please visit&nbsp; <a href="https://webglreport.com/" rel="nofollow">https://webglreport.com/</a> &nbsp;and copy/paste the WebGL1 report from there. Platform: Win32 Browser User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0 Context Name: webgl GL Version: WebGL 1.0 Shading Language Version: WebGL GLSL ES 1.0 Vendor: Mozilla Renderer: Mozilla Unmasked Vendor: Google Inc. Unmasked Renderer: ANGLE (AMD Radeon (TM) R7 370 Series Direct3D11 vs_5_0 ps_5_0) Antialiasing: Available ANGLE: Yes, D3D11 Major Performance Caveat: No Vertex Shader Max Vertex Attributes: 16 Max Vertex Uniform Vectors: 4096 Max Vertex Texture Image Units: 16 Max Varying Vectors: 30 Best float precision: [-2 127 , 2 127 ] (23) Transform Feedback Coming in WebGL 2 Rasterizer Aliased Line Width Range: [1, 1] Aliased Point Size Range: [1, 1024] Fragment Shader Max Fragment Uniform Vectors: 1024 Max Texture Image Units: 16 float/int precision: highp/highp Best float precision: [-2 127 , 2 127 ] (23) Framebuffer Max Color Buffers: 8 RGBA Bits: [8, 8, 8, 8] Depth / Stencil Bits: [24, 8] Max Render Buffer Size: 16384 Max Viewport Dimensions: [32767, 32767] Textures Max Texture Size: 16384 Max Cube Map Texture Size: 16384 Max Combined Texture Image Units: 32 Max Anisotropy: 16 Uniform Buffers Coming in WebGL 2 Supported Extensions: ANGLE_instanced_arrays EXT_blend_minmax EXT_color_buffer_half_float EXT_float_blend EXT_frag_depth EXT_shader_texture_lod EXT_sRGB EXT_texture_compression_bptc EXT_texture_filter_anisotropic OES_element_index_uint OES_standard_derivatives OES_texture_float OES_texture_float_linear OES_texture_half_float OES_texture_half_float_linear OES_vertex_array_object WEBGL_color_buffer_float WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_depth_texture WEBGL_draw_buffers WEBGL_lose_context To see draft extensions in Firefox, browse to about:config and set webgl.enable-draft-extensions to true. Game Link: <a href="https://app.roll20.net/campaigns/details/1214033/the-crimson-calamity" rel="nofollow">https://app.roll20.net/campaigns/details/1214033/the-crimson-calamity</a> Game Settings Was anything changed from default? I don't know what default it. It's on Pathfinder. Dynamic lighting was set up. Map Settings Are you using Legacy or Updated? I'm using the terribly horrible Update that has wasted countless hours of my prep and game time. Thanks for the "improvement". Were you using Explorer Mode or not? Yes Were you using Daylight Mode or not? No. Token Settings What kinds of light and vision were utilized on tokens? (bright light, low light, night vision, regular vision) I have a light token that emits light. My other tokens have vision. I literally just imported a new token and everything stopped working. Great system. Do you have Hardware Acceleration turned On or Off in your browser or system: I don't know. Oh I guess refreshing the page works. COOL. I can just have my players refresh fifty times a night. That'll be fun and won't break immersion at all.
1588437514

Edited 1588437747
Ane
Plus
Bug Report Template What you were trying to do: Play What happened: &nbsp;(Screen shots are useful here!) 1) Traditional Dynamic Lighting freezes my laptop 2) Updated Dynamic Lighting doesn't work at all. Traditional Dynamic Lighting is downright unplayable. I have to force restart my laptop 2-4 times per session. Maybe it's is because the maps are too big? I never had this problem in the past however. New dynamic lighting has the following issues (tested 10mins before writing this post) 1. Ctrl+L doesn't work at all. It just highlights the selected token. 2. I see the whole map as if dynamic lighting is disabled (as the DM) 3. The players see a blurry mess Pics :&nbsp; (One is the explorer's mode) Edit:&nbsp; While we are at it, I will also note that I had other minor bugs such as tokens looking semi-transparent to me, tokens turning unselectable and invisible for me while remaining there for the PCs, and other minor inconveniences, but I assume other ppl have reported those before and I am just reporting the above because I just tested them out. Steps to Reproduce: Just use dynamic lighting Browser &amp; OS info: Chromium Linux Mint Is WebGL supported by your browser? Yes Platform: Linux x86_64 Browser User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/80.0.3987.163 Chrome/80.0.3987.163 Safari/537.36 Context Name: webgl GL Version: WebGL 1.0 (OpenGL ES 2.0 Chromium) Shading Language Version: WebGL GLSL ES 1.0 (OpenGL ES GLSL ES 1.0 Chromium) Vendor: WebKit Renderer: WebKit WebGL Unmasked Vendor: Intel Open Source Technology Center Unmasked Renderer: Mesa DRI Intel(R) HD Graphics 620 (Kaby Lake GT2) Antialiasing: Available ANGLE: No Major Performance Caveat: No Game Link: &nbsp; I don't want random ppl joining my game,&nbsp; Game Settings Was anything changed from default? Map Settings Are you using Legacy or Updated? I tried both (yes I did disable the other while I was checking each of them) Were you using Explorer Mode or not? (I tried both, one pic is with explorer mode) Were you using Daylight Mode or not? (No) Token Settings What kinds of light and vision were utilized on tokens? (bright light, low light, night vision, regular vision)&nbsp; Night vision, regular vision Do you have Hardware Acceleration turned On or Off in your browser or system: No idea Speedtest Results &nbsp;PING ms 15 &nbsp;DOWNLOAD Mbps 50.32 &nbsp;UPLOAD Mbps 5.01 Please fix this thing. What was wrong with the old dynamic lighting?&nbsp; Also, while at it: Darkvision in 5e gives shadow illumination NOT bright light. If you could include that too it would be fine. If this isn't fixed by the time my subscription ends, I won't be resubbing until it is&nbsp; (and I won't have a way to know when it will get fixed)
Can we please have default vision based on race this way there isn't so much setup on each token/char.&nbsp; (5e)
Ane said: Maybe it's is because the maps are too big? Happens to me with regular maps they provide from the Marketplace. Ane said: If this isn't fixed by the time my subscription ends, I won't be resubbing until it is&nbsp; (and I won't have a way to know when it will get fixed) Honestly, I'm already looking at other options.&nbsp; They've yet to even acknowledge there's a problem with the regular Dynamic Lighting/AFOW.&nbsp; I may stay subscribed for one more month, just to give me time to re-create my games in an alternative VTT, so I don't leave my players high and dry.&nbsp; Roll20's got until then to give me a reason to stay.&nbsp; (And one place I was checking out seems to be getting a lot of Roll20 refugees....)
I tried using the updated dynamic lighting and none of my players could see unless they were emitting light. Nightvision didn't work at all and the majority of my players have darkvision in their features.&nbsp; My biggest issue is that it makes no sense for my players to have to emit their own light if they have darkvision and as one of my players has 120 ft darkvision its absurd to even make her emit that since the entire map would be illuminated for the entire party.
I'm insanely disappointed with this new dynamic lighting.&nbsp; I agree with Charlotte above me, but also there's no way to set 30/60 darkvision.&nbsp; Also, fog of war is crap under new system.&nbsp; Just making map where they were simply gray looks terrible.&nbsp; Way to nerf a good system.&nbsp; I'm starting to rethink my pro sub now.&nbsp;
1588451305

Edited 1588453254
I also have a random triangle of light in my map, that is not at all in range of any light source and the map is not in daylight mode. It seems to be in some way related to the zoom factor...
Wint said: Zachare S. said: At the moment, I'm not worried about Performance/Lag. When doing any kind of program development, you make the features, and then you make the system efficient afterwards. We're not out of Alpha, yet. I mean, yes, but also tell that all the people in this thread and watching these developments who are having major use issues even without the UDL turned on in their games. Also, this isn't exactly some free program in development. This is a paid feature, for a website that is several years old at this point. Roll20 as a company isn't some plucky lil' start-up out of two guys apartment anymore and shouldn't be treated as such. Oh, I heavily agree. I posted a simple fix that they could modify in code that would improve the old Advanced Fog of War performance by 80%. I mean, I can edit the source code myself and drop in a replacement JS File for myself and it decreases 0 FPS time from 8 seconds to 0.9 seconds, which is *very* significant. Its annoying that we're forsaking all of the changes that *could* be made to stem the tide of problems, and its making me check on other Tabletop solutions. =/
Jason B. said: There is still a glitch where my players can see what they’re &nbsp;not supposed to see if they’re to close to a wall or something. &nbsp;Like they can see through everything randomly until they wiggle their token. &nbsp;On character had night vision plus emotes 10ft of dim light cause of an item. &nbsp;Every time he was near a wall he could see everything. &nbsp;Had to switch back to old way. &nbsp;Don’t know if it matters. But I’m using google chrome on a mac. I put some information about the behavior I was seeing in a larger post, but I'm borrowing my wife's laptop and wanted to put something out there now in case developers are working on this this weekend. Regarding the map becoming partially or entirely visible, I have a bit more detail I think and can replicate it in my Baldur's Gate campaign on my account. This seems to be related to a few things occurring in sequence. The correction is the same as others mentioned, at least for the time being until it can be corrected in the code, and that is to wiggle or move the character in question once and things snap back. Generally, this seems to be as a result of players being on one tab and then moving to another, then returning and seeing more of the map than they should see. In short, they're seeing anything lit up anywhere on the map with dynamic light SOURCES regardless of dynamic light WALLS until they move their character which I'm assuming forces a redraw of sorts. To replicate this, I can swap tabs in the same Chrome window from roll20 to dndbeyond for example, then come back. The map still looks the same. Adding a new token didn't change anything and I was worried that that might have been the source. Instead enabling ANYTHING on the dynamic lighting tab for a token on the map in another room walled off by dynamic light walls is exposing all light sources on the map and they completely ignore all dynamic light walls. This means enabling vision on a token completely walled off from everything else was triggering this. So was enabling dim or bright light etc. Wiggling the token after this occurs restores things. Wiggling the token after returning from the non-roll20 tab and BEFORE applying anything on the dynamic light tab also fixed the problem (changing the dynamic light settings on the token did not cause the bad behavior). Hopefully this helps track the problem down more quickly and I'll do more testing with various Chrome windows as well to see if the tabbing matters or not in the same browser. Before (and after wiggling the token): What happens when applying dynamic light to an unrelated token away from the action, in this case the token in the room to the left. You can also see the lighting sources completely obliterate ALL dynamic walls at this point until a token controlled by the player is wiggled. You can also see the edges of a few more light sources in the bottom of the picture also bleeding up and ignoring all wall lines.
Testing the last bit of this was easier than expected. Having roll20 in its own chrome Window with no additional tabs helps. I was able to use a second window for dndbeyond on her computer and switching between them didn't cause problems. However, a few things did cause problems. Dragging the tab from dndbeyond into the window with roll20 caused the bug to replicate EVEN when I did not release the tab to lock it into the roll20 window. I would assume this means something about the non-roll20 tab stealing focus temporarily even though it was never confirmed and the tab was never added to that window. Similarly, the error still occurs if I make the non-roll20 tab full screen (again sounds like taking focus or something about the way that roll20 behaves or draws or renders when it is not the focus as a stab in the dark [cough]). I was also able to replicate this with another browser program which only causes problems when maximized on top of the chrome roll20 window. If I didn't maximize it didn't appear to cause problems even if I acted on the other Chrome window or other browser nearly completely covering the roll20 window. One last note is that I'm not sure when the light impact occurs, but as soon as I flip back to the roll20 window from another maximized window (or a tab on the same window) I can see the light change already in effect. If I don't make the change to the other token as the DM until after I flip back to the window, it takes place as soon as I hit save on the other token (hopefully this makes sense). This means that to some degree the STATE of being ready to have this light glitch seems to be readied as soon as fullscreen focus is taken up by another window or tab as the bug can manifest while the player is on another page/window or afterward if the DM doesn't make the change until a minute or two later AND THEY HAVE NOT MOVED THEIR TOKEN. Moving their token after returning from another maximized screen or tab seems to remove the state in which the bug occurs, possibly by somehow forcing the system to reconsider the dynamic light walls instead of ignoring them which seems to somehow be the issue.
ADD UPDATE ON DROP TO NEW DYNAMIC LIGHTING, I DONT WANT MY PLAYERS CHEATING. Thank you.
Zachare S. said: It appears that this update for switching Dynamic Lighting between Legacy and New has now affected the Legacy system. Prior to the update, scrolling the screen, typing, and clicking on things was on separate threads. You might have had to wait a little for the system to catch up, but you could queue up a few different actions. Unfortunately, today, when playing from 6pm to 10pm, it looks like updates on the map and scrolling around have been placed squarely on the same worker thread, the User Interface thread. What ends up happening is that if any player moves their token, everyone, including the player that moved the token freezes until the screen updates. With 5 players, it slowed down my games significantly. It appears that its only caused by moving the player's tokens, but it causes some severe problems. I've also noticed that loading time has *severely* increased (3-4x, upwards of 2 minutes in some cases). Settings: Fog of War - Off Advanced Lighting - On (Dim Light Reveals) Dynamic Lighting - On (Enforce Line of Sight, Only Update on Drop) New Dynamic Lighting - Off I have verified that every token does not have the new Dynamic Lighting system online. I also have verified that moving the tokens without players online causes the same issue. Being a programmer, I thought I'd do a little digging on what is going on. I did a performance check, and I found this d20.engine.advanced_fog.computeVisibleCells is being called many times. In fact, out of the 4952.7 milliseconds that we're being held on the same thread, this function is taking up 4929.7ms. This shows a *very* inefficient Function is being put right in the middle of the Render Thread, causing lockups from everyone. So, I did a little more debugging... It seems that, inside of this Advanced Fog, you're calling clone over and over again, called by this d20.math.sub. Cloning an object runs through and asks for each individual property of each individual thing to put back into this object, and then throw in modifications to that object. This is *extremely* inefficient... In your *BEST* case scenario, this is called three times in one execution. However, with this function, it is called *THOUSANDS* of times. Because of this constant cycle of cloning, substitution, and replacement, Roll20 ends up calling this function thousands of times with any map that has a decent number of lines to it. Now, this function normally wouldn't be a problem, but due to no caching going on with this function, and its average time to compute taking 0.7 milliseconds, a mildly complicated map will take about 4.5 seconds to compute *PER* move. What is the solution? Well, one thing that can be done is to stop using d20.math.sub as often as it is here. In fact, one call can be removed with const n = d20.math.sub(t,o), as it is already being stored at const i = d20.math.sub(t, o). If you need const n to be a substitution of d20.math.sub(t,o), then you can just change return d20.math.dot(s, a) to return d20.math.dot(s, i) The actual make of const n = d20.math.sub(t, o) is redundant, and leads to extra executions. The additional problem is that you can, instead, try to cache your outputs to keep those variables in memory without rebuilding them for every execution. Q: But won't n = d20.math.sub(t, o) be the same over and over again because its labelled as const? A: Ahh! No, it won't, because const doesn't mean that const is a constant like in C#. In JavaScript const actually means "readonly." It cannot be reassigned once set, but it acts like any other variable. If you end up closing an if statement, obliterating an anonymous function, that memory address is destroyed, and when you come back to the const variable, it builds it over again. Q: How would you prevent this from being calculated over and over again? A: I would label these as vars I could reassign, and instead of cloning, I would edit them directly. Unless I'm really paranoid that the individual items would be called by the initial function, I wouldn't utilize the cloning function. Its unnecessary bloat. If I'm worried that pre-calling functions would be messed up if I substituted an item, I would call clone(e) on the first line right after the function started, and set that as a variable. Then, I would substitute the variables inside of that new variable. Hey Zachare S. -&nbsp; Thank you for the awesome feedback here! Our development team is currently investigating this and we’ll be sure to keep you updated as we review!
1588480983

Edited 1588481013
You know I'm reading these reports of people saying that players can see everything when the GM moves tokens, and here I am getting the opposite problem.&nbsp; When I'm moving an NPC token my players will sometimes see nothing but the token they control and blackness for a second before it reverts.&nbsp; Not as big of an issue but it is kind of annoying for them to deal with.
Zachare S. said: Perfect setup :) They seem to be rolling out updates around every wednesday, so a new test like this every thurday, would just be perfect. I too look forward to the day that i can convert to the new system. one of the main issues is performance/lagging. You have a way of testing this?&nbsp; At the moment, I'm not worried about Performance/Lag. When doing any kind of program development, you make the features, and then you make the system efficient afterwards. We're not out of Alpha, yet. That being said, I do have a Performance Smoke Test, and here is my plan for once the major issues with UDL is updated. My plan is to execute two types of performance tests from two perspectives, GM and Player. The Performance will use the Google Performance Monitor to monitor length of time &lt;5fps, and ==0fps. It will also monitor ticks for me. The following tests are planned for me to execute: Move Non-Sighted, Non-Light Token 1 Cell from {not visible to not visible, not visible to visible, visible to not visible, visible to visible} Move Non-Sighted, Light Token 1 Cell {in sight visibility of a Sighted Token, not in sight visibility of a Sighted Token} Move Sighted, Non-Light Token 1 Cell Move Sighted, Light Token 1 Cell The plan is to setup the following three environments: Base Roll20 Setup with Advanced Fog of War + Legacy Dynamic Lighting in my normal setup. Modified Roll20 Setup with Advanced Fog of War + Legacy Dynamic Lighting. New Roll20 Setup with New Dynamic Lighting. The modified Roll20 Setup I will be replacing the Javascript files with the Google Chrome JS Replace in dev tools. As mentioned before, I found that _.clone was just causing an issue with performance and removing that one method call in the tests allowed for an 80% increase in performance. Once we get down to that there are only minor issues, I'll start doing Performance Comparison tests. For right now, I think that its not worth it as the code is changing a lot. That is awesome. But yes, proberly no idea in doing it now.&nbsp;
I have used Roll 20 for many years and promoted it as it has never let me down. Now I find since the Dynamic lighting update the system lags and is unpredictable in its performance. I've tried going from new system to legacy but it seems both systems now are corrupt, the only thing left is to turn both off and use reveal. My problems echo what I have read from above, I think timings were not the best with the Covid19 situation and more people playing online. Its about time Roll 20 updated its customers with a target date when these bugs will be fixed before people migrate to a more stable platform. Sorry Roll 20 you have gone from Hero to Zero at the moment! This bug report has not been updated for&nbsp; while.&nbsp; <a href="https://app.roll20.net/forum/post/8422745/a-new-light-bug-thread-updated-dynamic-lighting-and-fog-of-war" rel="nofollow">https://app.roll20.net/forum/post/8422745/a-new-light-bug-thread-updated-dynamic-lighting-and-fog-of-war</a> &nbsp;
Zachare, please inform us if you leave. That will be the time to leave as well. I am very disappointed by roll20 at the moment.
I am playing LMoP with my players. As we are slowly approaching Thundertree I was hoping that switching to new light will be good option and will boost performance. Performance is better but fog of war sometimes draws some bizzare shapes. Look at the slim line south east of the building and all and all those triangles. Overall it's better but those lines have almost glitchy look. And there are horrible issues if you zoom out. My browser is latest stable Edge on Chromium. New: Old: New: Old:
Sorry, I'm not a programmer and I don't know anything about coding I'm using Chrome and Windows 10 which is about all the technical stuff I can tell you about my system.&nbsp; But I have been working with Roll20 for about 6 weeks and have about 300 hours in the last 7 weeks into trying to figure out what is going wrong (nothing else to do with the Pandemic and I'm an obsessive personality).&nbsp; Everything worked fine until my game of April 23rd (it was working fine on the 16th and then when I logged into my game and noticed the Updated Dynamic Lighting thing and everything I had set up was not working anymore). That being said, here are a couple things I've noticed... On April 23rd, I suddenly had ridiculous levels of lag.&nbsp; Like it would take 2-3 minutes after a token was moved for it to show up on people's screen.&nbsp; This, or it would just lock up and I'd get the "webpage not responding wait/exit?" thing.&nbsp; If I'd pick wait 2-3 times, it would eventually update everything but it would take several minutes.&nbsp; I was using Dynamic Lighting, no global illumination with Advanced Fog of War, Reveal on Drop, show grid So I switched to UDL.&nbsp; This worked perfectly fine with one exception. At some random point in the game, suddenly one or more of my characters would be able to see all (or most) of the map.&nbsp; They would see everything as if Fog of war had been revealed to them.&nbsp; I noticed that the map was primarily a big giant arc of a circle and later realized this was due to a "sunlight" token with 240' range (in a 290' wide map) I had put at the far left of the map near a cave opening.&nbsp; This is why I was just seeing a big giant arc where this light would reveal things to people if there were no dynamic lighting lines on the map. So it seems like for some reason at some point, perhaps for only an instant, the Dynamic Lighting lines stopped functioning (probably for a split second as the view was FoW view and not line of sight) and allowed everyone to see through them into solid rock, through walls, etc. to the full range of the visible light provided by the sunlight token.&nbsp; I confirmed this by reducing the sunlight token range to 70' (all I really needed anyway) and when the error occurred, the FoW reveal view would only be 70' plus all the other torches and lamps I had throughout the dungeon.&nbsp; Since the FoW reveal showed solid rock areas and things you could not see at all, ever, if the DL lines were working, I had to assume that what was happening was the DL lines just stopped working for an instant and would reveal everything to everyone.&nbsp; I'm not sure what was causing this.&nbsp; Perhaps people were getting too close to the DL lines, were placing their tokens on the edge of the room overlapping the lines which made them not work?&nbsp; I'm afraid I don't know how the programming works so I can't say, I can only report my observations. So I switched back to Legacy Dynamic lighting with Advanced Fog of War and played around with that.&nbsp; I verified that I had global illumination off and verified that every single token, monster, lamp, chest, everything did not have UDL turned on in any way (as well as the map settings).&nbsp; I turned off everything I possibly could so all the monsters and NPCs had no vision or any sort of light settings.&nbsp; I reduced the number of oil lamps from 15 to 5 and took out half the Sun and dim light sun tokens lighting up the entrance of the cave. But still it was SO ridiculously slow that it was unplayable.&nbsp; About 4 minutes to update after moving a token and constant lock ups and drops. I discovered that if I took off AFoW, things ran smoothly... like perfect with no problems (other than not having any Fog of War which my players really want in this cave labyrinth).&nbsp; If I turned on AFoW, everything locked up or became so slow it was unusable. So I finally decided to create a test environment with AFoW and had everything set the same exact way as my original map, but with a very simple map, and very few DL lines (a 20x20 room with a passage coming out of it with a couple of turns), one monster with no vision in the room and one token with darkvision (emit 60' dim -5) assigned to a player, but not a character, that I could use to move around and see what happened. In this simplified situation, everything worked great!&nbsp; No problems at all. So I set about to recreate my original map which was I think 57 x 40 and was made up of a bunch of rough cave tunnels and mostly natural cave walls (oddly shaped).&nbsp; I had originally spent about 2 hours making little tiny clicks to get all the rough faces of the walls so the players could only see the surface of the walls as depicted in the map and not anything outside of that.&nbsp; So I did this again and it took me about 2 hours and a lot of hand cramping. When I finished, went back to the game with Dynamic Lighting on, but no AFoW and everything was fine.&nbsp; Vision was blocked as it should, I could have it update in real time (no update only on drop) and it worked fine as well.&nbsp; No problems and all is well. Then I turned on AFoW and WHAMMO!&nbsp; Everything became really laggy.&nbsp; Not as bad as before, it was only taking about 30 seconds for a token to update, but I didn't have any monster tokens, external lighting, and I only did part of the walls (leaving out the islands and pillars, stalactites/stalagmites). So assuming that perhaps the very complicated DL lines (perhaps hundreds if not thousands of tiny lines along the rough edges of the walls) were causing some sort of massive calculations when the program was doing the AFoW stuff, maybe a less complicated DL layer would make things better.&nbsp; I had assumed that if regular sight/vision with Dynamic Lighting had no problem with vision and revealing what was in a players line of sight when there were highly complex Dynamic Lighting Lines, why would the AFoW be negatively impacted by this.&nbsp; But it seemed it was. So I deleted all my complicated DL lines and replaced them with much longer and straighter lines.&nbsp; This of course resulted in the player view showing into the solid rock walls more and it became a little tricky at junction points or around corners.&nbsp; I probably reduced the number of lines by 80% or so... just a guess. When I went back into the game with DL on and no AFoW, everything was running smooth and perfect (as expected).&nbsp; When I turned on AFoW... it was usable.&nbsp; I mean there was a bit of a delay, maybe 1-2 seconds after a token was moved, but it was usable. This led me to the assumption that there is something going on with AFoW that is causing massive recalculation anytime anything changes, a token is moved or anytime the AFoW needs to be updated (there was a problem moving tokens even in areas that had already been fully revealed by AFoW however, so just when a token is moved, the calculations slow down occurs whether there is new revealing or not). This seems to be in agreement to what Zachare S. has been talking about above (I can't say I understand all the technical stuff he talks about with the coding and everything, but I understand enough to agree with what he seems to think the problem is - Thank you Zachare S. for your detailed work on this issue).&nbsp; It looks like when AFoW is switched on now, there are some sort of massive number of calculations being done which slow things down like crazy. In the short term, I'll convert my game map to the less complicated DL line option (while not ideal, it will at least allow us to play with DL and AFoW but players will see into the walls a bit around the edges of the rough walls and curvy passages).&nbsp; Hopefully the developers will be able to fix this issue with AFoW so it's not doing a million calculations every time a token is moved.&nbsp; And hopefully at some point UDL will not suddenly reveal the entire map to the players as if the DL lines just stopped working for an instant. But until that time I can get by and still play with about 80% of what I wish it would do. I don't know if this information helps anyone who is trying to use DL and AFoW in Legacy, but hopefully it will.&nbsp; I have lots of test information so if anybody is still having trouble getting AFoW to work, let me know and I can maybe help you figure out how to make it at least playable while things get worked out.
Another quick update regarding the "entire page reveal" issue as a result of moving to a browser tab or maximizing another program on top of the VTT. Testing tonight before playing with the full group, we saw a combination of behaviors with the Mac user seeing the screen entirely revealed, but three PC players seeing the screen go entirely black instead of revealing the entire map. For tonight we'll be having each player use a separate Chrome Window and try not to maximize a window on top of it and see how that goes. More to come.
Okay so not only am I not the only one that has experianced the "players see nothing" problem but someone (sorta) caught it on camera.&nbsp; I've put a link to a bit before it happens.&nbsp; I say sorta because we only hear about the players see nothing thing.
Missingno said: Okay so not only am I not the only one that has experianced the "players see nothing" problem but someone (sorta) caught it on camera.&nbsp; I've put a link to a bit before it happens.&nbsp; I say sorta because we only hear about the players see nothing thing. My group has been experiencing this as well, even on Legacy Dynamic lighting. Ever since the UDL was pushed I can only get maybe working sometimes "UDL" (kind of worked for about 5 minutes for some players) or a completely broken LDL (no vision at all for anyone).
1588633279
Julien De Lucca
Pro
Marketplace Creator
The new system is coming up greatly! Only a couple of pointers: 1 - I would love to see a slider for Global Illumination in the new mode. Either is FULLY LIT or COMPLETE BLACK which is odd. We could have a slider that sets the overal Ambient Light for Global Illumination. In the new mode, when you have a token with VISION looking at a corridor that has lights coming from the side corridors, the visual is weirdly full of pitch black triangles. This can be resolved when a token emits only low light - which looks great by the way - however there's currently no option "All Players See Light" to turn off so only that controlling player can see its immediate surroundings. 2 - The old Advanced Fog of War was much darker than Explorer Mode. In dungeons with gray tiles, its almost impossible to differentiate what's been explored from what's currently being seen. Please allow us to set the darkness of what's already been explored. 3 - Darkvision should have a smooth outer border. Thanks for all the effort and support you're all doing!! Gotta love R20!
The hide area tool's not working for me.
I am having a problem with the legacy lighting that I have never had before.&nbsp; When I set-up lighting, I draw red lines for walls, and leave gaps for the doors.&nbsp; I then draw green lines for the doors.&nbsp; When the players open doors, I delete the green lines that cover them up., to let the players see.&nbsp; Lately, I have been unable to select some of the green lines.&nbsp; Therfore, I cannot delete the doors to "open" them, because I cannot select them.&nbsp; Here is a screen shot: &nbsp;&nbsp; In this picture, the green line leading into the room with the centepedes cannot be deleted or even selected.&nbsp; The door below it had a line that I was able to select and delete.&nbsp; The red lines (the walls) are also selectable. This is creating quite a problem for me, because it is sealing off rooms. Again, this is with the legacy lighting.&nbsp; And I have never had this problem until recently. Thank you!&nbsp;
1588645961

Edited 1588645987
keithcurtis
Forum Champion
Marketplace Creator
API Scripter
It is a problem that people report from time to time. There are two things you can do that might help. 1) Use thicker lines. 2) Hold down the Alt key and drag a selection rectangle over the door. Alt constrains selections to drawings only, incase you have any light-emitting tokens on the DL layer you don't want to accidentally move.
Thanks keithcurtis.&nbsp; It is happening to me all the time now, though.&nbsp; Not time to time.&nbsp; I have another map where it has happened 3 times, that I just did today.&nbsp; Drawing a selection box does not help at all, regardless of whether I press Alt.&nbsp; I have just realized that it only happens to me with vertical lines though.&nbsp; Horizontal and diagonal lines are not causing a problem.&nbsp; Don't know if that will help them debug it.&nbsp;
1588709598

Edited 1588709709
Jay R, I wanted to check back in regarding the Ctrl-L issue where the entire map reveals itself ( as discussed here ), are the two of you still experiencing the issue? We're having a lot of trouble recreating the problem. Could you provide us with detailed recreation steps so we can see if we're missing something on our end?