Updated Dynamic Lighting - Feedback Thread

SlendyMcTendies said: For the Updated Dynamic Lighting Cone View bug, one I reach a total of roughly 15 or more objects on the map and/or token layer having vision and/or giving off light, vision starts to break and is forced into a 90 degree cone. Hi there, Thanks for this information. We're aware of this issue and your report will help guide our team toward a fix!

Last night was my first gaming session since the UDL update came out, and we basically had a 2 and a half hour chat session because the game was close to unplayable. I run a Intel i7 10th Gen with 16gb RAM and a Geforce 2060RTX, both firefox and chrome ran LDL without any performance issue at all. I'm running a a pretty large map and my players have never had issue with the game (do not know their specs) Last night we ran into the following issues 1) severe lag. It took me about 50 seconds for a single die roll at one point 2) Constant browser crashes. The players routinely had to log out and try a different browser. 3) Tokens randomly freezing 4) Dice not rolling. This was an odd one. I'm using the Moldvay record sheet for BECMI and it has a macro to roll for attack that rolls both your to hit and damage. For some reason last night, it was only rolling the damage randomly. 5) The game just decided to show one player the entire map. No rhyme nor reason....just "Hey, here's the map in all it's glory". That was an odd one. All in all, it was an incredibly maddening session. We were online about 2 and a half hours, and actually played about 45 minutes.

I ran into an issue using the UDL Conversion Tool and I was wondering if anyone here could give me some advice. I had experimented a little with UDL back in April, but after some frustration I decided to stick with LDL.  The recent official e-mail / posts related to UDL and the LDL sunsetting gave me the impression that things would be better this time around.  The actual instigating event was a player in my game complaining of poor performance with LDL and I assumed (naively it turned out from what I've since read) that UDL would offer better performance. I decided to dip my toes by using the UDL Conversion Tool to convert a single map (the one that had some performance issues) to UDL and to leave the Journal alone.  Conversion ran fine and the map even seemed to run a bit more smoothly (no RAM issues on my system which may explain things). The problem was that I couldn't drag any new tokens to the page.  Or any page as it turned out.  At this point, I suspected that leaving out the Journal had caused a problem so I made a copy of my game (wish I had done that first) and tried converting everything.  The token issue persisted. I eventually realized that the Conversion Tool had corrupted the default tokens for every token in the game.  It was possible to get them working again by deleting the existing default token and setting a new one.  For tokens that were already on a map, I could use the existing token created before the UDL experiment, but for it's going to be pretty tedious finding every monster spread across the many pages and resetting them one by one. A general question first: has anyone else experienced this and are there any easy solutions?  I filed a bug report but I didn't get much in my searches so I don't know if this known. Failing that, is this fixable programatically through the API?  I don't have much experience with it, but I do a fair bit of programming so provided it's possible, I feel comfortable that I can manage.  My campaign is 5e (Curse of Strahd) and I think all I'd need to do is delete each default NPC token, set it to the existing image, and set some Bar values.  Am I missing anything important? Thanks for the help Jamie

Deciding to continue the pattern. First it was in test servers which is where it belongs. Then, they put it into all games where it was unclearly labeled as a test feature and frankly made it confusing to change between UDL and LDL. Now they are forcing this Beta product on everybody, forcing paying subscribers to test an unfinished product. No, I won't list my issues, assist with debugs, I will simply take my business elsewhere.

Brian C.  said: This is irresponsible. Given the number of game-breaking bugs still in UDL (and the conversion tool) and that many of the new versions of features have a detrimental effect on game play, who decided that a general broadcast that UDL is ready for primetime was a good idea? There are going to be a lot of people who do not follow these bug threads who are in for some nasty surprises. I posted this  over a week ago. In that time, we have seen numerous accounts of paying customers losing game sessions and having their games corrupted by the conversion tool, entire maps revealed to the players, vision only revealing a small angle of the map, and games grinding to a halt. I dismissed that notification, knowing that UDL and the conversion tool are dangerous to use in anything but a test environment. . . and now it's back? Why has the notification been restored when the system is obviously still not ready? Software should be nearly bulletproof when it is released to production. UDL and the conversion tool are still in a state where they really belong on the Dev server, and they  really should not have repeated notifications telling unsuspecting users to convert their games.

James M. said: I ran into an issue using the UDL Conversion Tool and I was wondering if anyone here could give me some advice. I had experimented a little with UDL back in April, but after some frustration I decided to stick with LDL.  The recent official e-mail / posts related to UDL and the LDL sunsetting gave me the impression that things would be better this time around.  The actual instigating event was a player in my game complaining of poor performance with LDL and I assumed (naively it turned out from what I've since read) that UDL would offer better performance. I decided to dip my toes by using the UDL Conversion Tool to convert a single map (the one that had some performance issues) to UDL and to leave the Journal alone.  Conversion ran fine and the map even seemed to run a bit more smoothly (no RAM issues on my system which may explain things). The problem was that I couldn't drag any new tokens to the page.  Or any page as it turned out.  At this point, I suspected that leaving out the Journal had caused a problem so I made a copy of my game (wish I had done that first) and tried converting everything.  The token issue persisted. I eventually realized that the Conversion Tool had corrupted the default tokens for every token in the game.  It was possible to get them working again by deleting the existing default token and setting a new one.  For tokens that were already on a map, I could use the existing token created before the UDL experiment, but for it's going to be pretty tedious finding every monster spread across the many pages and resetting them one by one. A general question first: has anyone else experienced this and are there any easy solutions?  I filed a bug report but I didn't get much in my searches so I don't know if this known. Failing that, is this fixable programatically through the API?  I don't have much experience with it, but I do a fair bit of programming so provided it's possible, I feel comfortable that I can manage.  My campaign is 5e (Curse of Strahd) and I think all I'd need to do is delete each default NPC token, set it to the existing image, and set some Bar values.  Am I missing anything important? Thanks for the help Jamie I experienced the same issue using a test game. Tokens all got corrupted with the tool, which meant that I had to recreate tokens for every character sheet. Which makes it unusable in any game situation. No acknowledgment from development that this problem even exists despite multiple users reporting it. And it is NOT hard to reproduce. And I am not wasting my time filling out huge bug report forms and essentially doing Roll20's QA job for them on an easily reproducible, game-breaking issue. I am a customer. I don't work for Roll20 and I don't get paid by them. The amount of QA customers are expected to do here is frankly appalling.

Nathan K. said: Deciding to continue the pattern. First it was in test servers which is where it belongs. Then, they put it into all games where it was unclearly labeled as a test feature and frankly made it confusing to change between UDL and LDL. Now they are forcing this Beta product on everybody, forcing paying subscribers to test an unfinished product. No, I won't list my issues, assist with debugs, I will simply take my business elsewhere. I understand your frustration, and share it myself. It's not just the specific issues with UDL, it's the same old pattern, as you noted. Not listening to your customers, rolling out horrendous, bug-filled products before they're ready, not being responsive to user reports, and then foisting a product that is clearly not ready on the general public, likely because those in charge had a specific timetable in their minds and want to stick to it regardless of whether the product actually works or not. I really hoped that after the AFoW debacle of 2019, Roll20 would have learned from its mistakes, but apparently not. I am now actively exploring other VTT options.

Brian C. said: Brian C.  said: This is irresponsible. Given the number of game-breaking bugs still in UDL (and the conversion tool) and that many of the new versions of features have a detrimental effect on game play, who decided that a general broadcast that UDL is ready for primetime was a good idea? There are going to be a lot of people who do not follow these bug threads who are in for some nasty surprises. I posted this  over a week ago. In that time, we have seen numerous accounts of paying customers losing game sessions and having their games corrupted by the conversion tool, entire maps revealed to the players, vision only revealing a small angle of the map, and games grinding to a halt. I dismissed that notification, knowing that UDL and the conversion tool are dangerous to use in anything but a test environment. . . and now it's back? Why has the notification been restored when the system is obviously still not ready? Software should be nearly bulletproof when it is released to production. UDL and the conversion toll are still in a state where they really belong on the Dev server, and they  really should not have repeated notifications telling unsuspecting users to convert their games. I'm already leaning toward moving to another VTT. Aside from the fact that Roll20 shouldn't be treating their paying customers as their QA team, UDL is horrific and it doesn't seem like anything is getting corrected in a timely manner. In fact, some of the issues I reported in March are still not fixed (ghostly images when zooming, no low-light vision option, hard to see differentiation with fog of war). And now Roll20 is making this statement that they have reached "feature parity" with LDL and LDL is now considered in "sun setting" status. I don't understand how they can make that statement. The primary reason I'm still here is because LDL is still working. Roll20 should not remove LDL without some major updates/fixes/improvements to UDL. There are other systems that do UDL better with more features already; Roll20 is just easier to use as a platform for the GM and player.

It is disheartening to see UDL billed as ". . . available with all of the same features as Legacy Dynamic Lighting—and more." UDL has taken a step backward in several areas. Multiple aspects of dynamic lighting have seen significant changes that have a detrimental effect on the play experience or the available options for the GM. DL lines block vision from the edge instead of the middle. First reported July 3 and again  here . DL lines block vision from the middle of the line in LDL. In UDL, they block vision from the edge of the line. This means that anything but the thinnest DL lines will obscure more of the map, which is especially a problem when a DL line must be drawn down the middle of a wall or door because the player tokens can approach the line from either side. A thicker line leaves the players wondering, "Is it a door? Is it a wall? I don't know!" It also means that secret doors that were set up with a thicker line than the adjoining wall will leap out at the players when the game is converted to UDL. Additionally, UDL uses more than twice as many lines as LDL for some reason. This means that UDL already has to do more than twice as much work to check where DL lines block vision (and also allowing you to put a token within a wall). Dynamic Lighting walls are jagged LDL works pretty well when only looking at Dynamic Lighting and skipping AFoW. The system runs at a decent speed. It is surprising then that the Dynamic Lighting portion appears to have been largely rebuilt from the ground up for UDL rather than improving on the existing system. In LDL, the system appears to be calculating what can be seen in blocks. In contrast, UDL appears to have traded this for some form of raycasting. At least, that is my guess as to why the unsightly stair stepping has been introduced at the edges of a token's vision (such as in the image above). In contrast, the same DL line gives a smooth surface in LDL. The loss of 5e darkvision I know that not everyone plays 5e, but it represents over 50% of the games played / time spent on Roll20. 5e darkvision allows a creature to see in darkness as shades of grey and in dim light as if it were bright light. LDL did not provide grayscale, but it gave the next best thing by allowing a GM to provide darkvision by setting a token's light to 60/0. This provides dim light to 60 feet, and it combined with other dim light sources to let the player see an area as if it were bright light. In UDL we have 3 options, none of which approximate the level of functionality in LDL: Night Vision provides bright light. Night Vision provides bright light with a visual distortion to show where it ends. Night Vision provides bright light with a color overlay to differentiate it. Option 1 only works for warlocks with the Devil's Sight invocation. Option 2 looks terrible, especially if a player controls multiple tokens and the night vision fields overlap. Option 3 looks nothing like dim light unless you choose black as the tint color. This has the unfortunate problem of having "light" that makes things  darker . As soon as two tokens controlled by a player overlap, they completely obscure the map. In UDL, Night Vision with tinting makes a dim light source slightly  darker  rather than brighter. The loss of "hard edges" on light sources. In LDL, you can make a light source have a "hard edge" by setting both fields of Emits Light to the same value (i.e. 10/10). This is good for a spotlight to point out something on the page and allowed the "full" distance to be bright light rather than fading out. UDL is locked into one width of fading out for the edge. The torch on the left is set to 10/10. The torch on the right is set to 10/blank, which gives the same result as UDL's 10 feet of bright light.

James M. said: I ran into an issue using the UDL Conversion Tool and I was wondering if anyone here could give me some advice... Playing with it a little more, I've noticed that it also removed the "Character Sheet" tab from every NPC / Monster journal entry.  I'm at a bit of a loss on what to do now.  The only thing I can think of is to create a new blank campaign and use the transmogrifier to transfer tokens to my existing game. Thoughts? Thanks again

James M. said: James M. said: I ran into an issue using the UDL Conversion Tool and I was wondering if anyone here could give me some advice... Playing with it a little more, I've noticed that it also removed the "Character Sheet" tab from every NPC / Monster journal entry.  I'm at a bit of a loss on what to do now.  The only thing I can think of is to create a new blank campaign and use the transmogrifier to transfer tokens to my existing game. Thoughts? Thanks again Check the Settings->Game Settings page (accessed from the game's launch page) and see if you lost the character sheet template setting. If you set it back to the correct sheet, the character sheets should reappear.

Brian C. said: James M. said: James M. said: I ran into an issue using the UDL Conversion Tool and I was wondering if anyone here could give me some advice... Playing with it a little more, I've noticed that it also removed the "Character Sheet" tab from every NPC / Monster journal entry.  I'm at a bit of a loss on what to do now.  The only thing I can think of is to create a new blank campaign and use the transmogrifier to transfer tokens to my existing game. Thoughts? Thanks again Check the Settings->Game Settings page (accessed from the game's launch page) and see if you lost the character sheet template setting. If you set it back to the correct sheet, the character sheets should reappear. Thanks - That fixed the character sheet issue. In playing around with the Transmogrifier, it gives me a relatively quick way of resetting the messed up tokens I described above.  There are some NPCs / Monsters that I've tweaked from their initial stats (can't Transmogrify those without losing changes), but at least this will let me get most things back to normal without wasting too much more time.

I'm completely new to DL and UDL as such I have no idea if I'm doing something wrong or it's broken to the point of uselessness. Random patches of light/ darkness that grow and move as you pan. Technicolor lines akin to the northern lights appearing while i select tokens or draw dynamic lighting. Hope its all ironed out so I can learn this! 

One of my player has 'god-level' vision.  He can see everything on the token layer. I've taken away vision on his token entirely and that didn't fix it. 

The new Dynamic lighting is unusable for me. Namely at higher zoom levels everything gets this weird pixelating effect, that makes text hard to read, and now have an issue where tokens on the GM layer disappear. Tested in Firefox, MS Edge, and Chrome. Without new Dynamic Lighting: (higher res images:&nbsp; <a href="https://imgur.com/a/KfuBmoq" rel="nofollow">https://imgur.com/a/KfuBmoq</a> ) After enabling Dynamic Lighting:

Brian C. said: It is disheartening to see UDL billed as ". . . available with all of the same features as Legacy Dynamic Lighting—and more." UDL has taken a step backward in several areas. Multiple aspects of dynamic lighting have seen significant changes that have a detrimental effect on the play experience or the available options for the GM. DL lines block vision from the edge instead of the middle. First reported July 3 and again&nbsp; here . DL lines block vision from the middle of the line in LDL. In UDL, they block vision from the edge of the line. This means that anything but the thinnest DL lines will obscure more of the map, which is especially a problem when a DL line must be drawn down the middle of a wall or door because the player tokens can approach the line from either side. A thicker line leaves the players wondering, "Is it a door? Is it a wall? I don't know!" It also means that secret doors that were set up with a thicker line than the adjoining wall will leap out at the players when the game is converted to UDL. Additionally, UDL uses more than twice as many lines as LDL for some reason. This means that UDL already has to do more than twice as much work to check where DL lines block vision (and also allowing you to put a token within a wall). Dynamic Lighting walls are jagged LDL works pretty well when only looking at Dynamic Lighting and skipping AFoW. The system runs at a decent speed. It is surprising then that the Dynamic Lighting portion appears to have been largely rebuilt from the ground up for UDL rather than improving on the existing system. In LDL, the system appears to be calculating what can be seen in blocks. In contrast, UDL appears to have traded this for some form of raycasting. At least, that is my guess as to why the unsightly stair stepping has been introduced at the edges of a token's vision (such as in the image above). In contrast, the same DL line gives a smooth surface in LDL. The loss of 5e darkvision I know that not everyone plays 5e, but it represents over 50% of the games played / time spent on Roll20. 5e darkvision allows a creature to see in darkness as shades of grey and in dim light as if it were bright light. LDL did not provide grayscale, but it gave the next best thing by allowing a GM to provide darkvision by setting a token's light to 60/0. This provides dim light to 60 feet, and it combined with other dim light sources to let the player see an area as if it were bright light. In UDL we have 3 options, none of which approximate the level of functionality in LDL: Night Vision provides bright light. Night Vision provides bright light with a visual distortion to show where it ends. Night Vision provides bright light with a color overlay to differentiate it. Option 1 only works for warlocks with the Devil's Sight invocation. Option 2 looks terrible, especially if a player controls multiple tokens and the night vision fields overlap. Option 3 looks nothing like dim light unless you choose black as the tint color. This has the unfortunate problem of having "light" that makes things&nbsp; darker .&nbsp;As soon as two tokens controlled by a player overlap, they completely obscure the map. In UDL, Night Vision with tinting makes a dim light source slightly&nbsp; darker &nbsp;rather than brighter. The loss of "hard edges" on light sources. In LDL, you can make a light source have a "hard edge" by setting both fields of Emits Light to the same value (i.e. 10/10). This is good for a spotlight to point out something on the page and allowed the "full" distance to be bright light rather than fading out. UDL is locked into one width of fading out for the edge. The torch on the left is set to 10/10. The torch on the right is set to 10/blank, which gives the same result as UDL's 10 feet of bright light. I would REALLY like to see some substantive and timely response from Roll20 to Brian's excellent post. Given the above, how can Roll20 justify saying UDL is ready to replace Legacy?

PunyPaladin said: One of my player has 'god-level' vision.&nbsp; He can see everything on the token layer. I've taken away vision on his token entirely and that didn't fix it.&nbsp; I'm in the same boat. I spent hours preparing a map, adding light "block outs" around it, filling dungeons....only to have all the surprises of the map spoiled by a poorly executed update. For ten years, I worked as a Network Engineer for a major payment gateway and served as QA on countless code pushes. This release screams of a lack of testing across multiple platforms to ensure stability and impatient developers pushing code well before it was ready to be released into the wild.

Am I taking crazy pills? Because that's what it feels like. UDL is nowhere near ready, it is unusable at time of writing.&nbsp;UDL should be called JBL (janky broken lighting) at present. I really REALLY &nbsp;hope that the developers listen to community feedback and decide against "sunsetting" the old dynamic lighting system (you know, the one that actually works) until there is true feature parity with UDL.&nbsp; Just because you assert that it is feature complete does not make it so. If they get rid of LDL I will have to cancel my subscription in all likely-hood. I can't justify the price-tag if the main selling point no longer functions.

Jay R. said: Brian C. said: It is disheartening to see UDL billed as ". . . available with all of the same features as Legacy Dynamic Lighting—and more." UDL has taken a step backward in several areas. Multiple aspects of dynamic lighting have seen significant changes that have a detrimental effect on the play experience or the available options for the GM. DL lines block vision from the edge instead of the middle. First reported July 3 and again&nbsp; here . DL lines block vision from the middle of the line in LDL. In UDL, they block vision from the edge of the line. This means that anything but the thinnest DL lines will obscure more of the map, which is especially a problem when a DL line must be drawn down the middle of a wall or door because the player tokens can approach the line from either side. A thicker line leaves the players wondering, "Is it a door? Is it a wall? I don't know!" It also means that secret doors that were set up with a thicker line than the adjoining wall will leap out at the players when the game is converted to UDL. Additionally, UDL uses more than twice as many lines as LDL for some reason. This means that UDL already has to do more than twice as much work to check where DL lines block vision (and also allowing you to put a token within a wall). Dynamic Lighting walls are jagged LDL works pretty well when only looking at Dynamic Lighting and skipping AFoW. The system runs at a decent speed. It is surprising then that the Dynamic Lighting portion appears to have been largely rebuilt from the ground up for UDL rather than improving on the existing system. In LDL, the system appears to be calculating what can be seen in blocks. In contrast, UDL appears to have traded this for some form of raycasting. At least, that is my guess as to why the unsightly stair stepping has been introduced at the edges of a token's vision (such as in the image above). In contrast, the same DL line gives a smooth surface in LDL. The loss of 5e darkvision I know that not everyone plays 5e, but it represents over 50% of the games played / time spent on Roll20. 5e darkvision allows a creature to see in darkness as shades of grey and in dim light as if it were bright light. LDL did not provide grayscale, but it gave the next best thing by allowing a GM to provide darkvision by setting a token's light to 60/0. This provides dim light to 60 feet, and it combined with other dim light sources to let the player see an area as if it were bright light. In UDL we have 3 options, none of which approximate the level of functionality in LDL: Night Vision provides bright light. Night Vision provides bright light with a visual distortion to show where it ends. Night Vision provides bright light with a color overlay to differentiate it. Option 1 only works for warlocks with the Devil's Sight invocation. Option 2 looks terrible, especially if a player controls multiple tokens and the night vision fields overlap. Option 3 looks nothing like dim light unless you choose black as the tint color. This has the unfortunate problem of having "light" that makes things&nbsp; darker .&nbsp;As soon as two tokens controlled by a player overlap, they completely obscure the map. In UDL, Night Vision with tinting makes a dim light source slightly&nbsp; darker &nbsp;rather than brighter. The loss of "hard edges" on light sources. In LDL, you can make a light source have a "hard edge" by setting both fields of Emits Light to the same value (i.e. 10/10). This is good for a spotlight to point out something on the page and allowed the "full" distance to be bright light rather than fading out. UDL is locked into one width of fading out for the edge. The torch on the left is set to 10/10. The torch on the right is set to 10/blank, which gives the same result as UDL's 10 feet of bright light. I would REALLY like to see some substantive and timely response from Roll20 to Brian's excellent post. Given the above, how can Roll20 justify saying UDL is ready to replace Legacy? I would also love to hear from roll20 on what they plan to do about any and all of these bugs / "features" before they even THINK of removing LDL

Going to be watching this months round table with interest.&nbsp; I wonder if they will finally admit that UDL is far from being ready or even remotely close to parity with LDL?&nbsp;

Hello, not sure if this is the place to ask (if not, please move my post to relevant forum). In the Legacy lightning, I could give a token a "multiplier" if it had low-light vision (i.e. it could see twice as far). How do I do that in the new Dynamic Lighting?

Arandor B. said: Hello, not sure if this is the place to ask (if not, please move my post to relevant forum). In the Legacy lightning, I could give a token a "multiplier" if it had low-light vision (i.e. it could see twice as far). How do I do that in the new Dynamic Lighting? It is in the "Advanced" section at the bottom of the settings.&nbsp; You need to click the little arrow by Advanced to expand the window to see it.&nbsp; Instead of a multiplier, it is a percentage, so you would change the 100 to 200 to get the same result as setting the multiplier to 2 in the legacy system.

jason the dm&nbsp; said: No. They are using you to develop their software. You've been hired to find bugs and report on them. And no you don't get paid for your work Such vitriol. If you feel so strongly about it, just don't use the system until it's ready and finished. It's really that simple. Anyway, one feature I've really wanted for a long time is one-way dynamic lighting. Any way to implement that with the new system? For example, I often put dynamic lighting around buildings in a town. But a player on a rooftop should not be subject to that lighting. It would be nice if that dynamic lighting is only active to people outside that effect. Thus, one-way dynamic lighting. I.e., it only impede vision for sightlines going through one direction of the polygon.

Bret R. said: jason the dm&nbsp; said: No. They are using you to develop their software. You've been hired to find bugs and report on them. And no you don't get paid for your work Such vitriol. If you feel so strongly about it, just don't use the system until it's ready and finished. It's really that simple. Anyway, one feature I've really wanted for a long time is one-way dynamic lighting. Any way to implement that with the new system? For example, I often put dynamic lighting around buildings in a town. But a player on a rooftop should not be subject to that lighting. It would be nice if that dynamic lighting is only active to people outside that effect. Thus, one-way dynamic lighting. I.e., it only impede vision for sightlines going through one direction of the polygon. The vitriol is from someone who has paid for a feature that still does not work.&nbsp; Many of us feel that way.&nbsp; What is absurd is that you are asking for new features when they haven't even gotten "Parity" features working.&nbsp; Are you sure you don't work for Roll20?&nbsp; I mean that has been their mode of operation since forever.&nbsp; As an example, AFOW was broken last year and after some amount of time, they just gave up and said "We are working on a refactoring of DL that will allow for so many new options and features".&nbsp; Here we are over a year later and guess what!&nbsp; We still don't have the functionality.&nbsp; So yes, some vitriol for a product that we pay for that doesn't provide features we pay for.&nbsp;&nbsp; And Yes, we are their QA department, obviously.&nbsp; The want us to test it, and provide them with Console Logs, and give them feedback as they attempt to get it right.&nbsp; Although gone now, I noticed one of their announcements was for a new QA Engineer.&nbsp; I thought to myself, why, they have all of us paying customers.

Sewer Crew Gaming said: Am I taking crazy pills? Because that's what it feels like. UDL is nowhere near ready, it is unusable at time of writing.&nbsp;UDL should be called JBL (janky broken lighting) at present. I really REALLY &nbsp;hope that the developers listen to community feedback and decide against "sunsetting" the old dynamic lighting system (you know, the one that actually works) until there is true feature parity with UDL.&nbsp; Just because you assert that it is feature complete does not make it so. If they get rid of LDL I will have to cancel my subscription in all likely-hood. I can't justify the price-tag if the main selling point no longer functions. I'm in the same boat. If they go through with this absurd push to UDL when it is broken and clearly not ready, they will lose my business.

I Finally Decided to use UDL and it was working better than ever, then after this past Saturday a hot fix was put out by Roll20 Dev team and now all my UDL work on all my maps, plus tokens is gonna have to be switched back to Legacy bc you went and broke the new lighting, its unusable now, bc now every token is auto given broken unchangeable field of vision something i never use on any token. now is auto activated and cant be changed bc its written in some weird hot fix you put out to fix this now makes it permanent unchangeable token feature. my token placed before hotfix works fine, Now any new token or player token placed turns to this. &nbsp; If this can be undone before my next session, would save me atone of redoing everything back to legacy lighting.

Shane (and also Paul N possibly), Shane said: I'm really trying not to jump onto the negative bandwagon.&nbsp; I tried my game today and the nightvision being in a cone was fixed.&nbsp; However, about the 3rd room in, the dynamic lighting in the game went away and everyone in the game was able to see the entire map.&nbsp; I'm not sure why or how.&nbsp; Two players' browsers had to reset a few times while we were playing.&nbsp; And then the map was entirely visible to the group.&nbsp; All online players saw it.&nbsp; Not sure how that is one person's fault and not the system.&nbsp; I had to revert to the old system and use the fog of war with manual reveal.&nbsp; I've been paying for a top tier subscription for over two years to use the dynamic lighting system with the promise that it's just around the corner.&nbsp; Now it's here and I still can't use it.&nbsp; And it's with official maps that I purchased from Roll20.&nbsp; Really disappointed since it is now in fully functional mode but hanging on for now. Some of my players have this behavior periodically as well and I can share a few "solutions" that might help in the interim. First, unless it has been corrected, some players notice problems when a) swapping between tabs/browser windows or b) opening another application on top of the roll20 window. This would appear to be causing some kind of render or re-render issue that exposes the entire screen to some players when they return to the roll20 window. This behavior seems to be tied to the more important second point below. In order to avoid this, have players put their roll20 window in a separate window and try to avoid opening tabbing or opening other windows/applications on top of the roll20 window. I know this isn't a good solution, but it seems to work most of the time. Second, when the DM makes changes to the UDL layer this can pose problems exposing the entire map. Such events include major things such as turning UDL off/on (even when daylight mode is not enabled) or checking the box to only enable vision on token drop etc. This also can trigger for minor events such as toggling vision on/off for a player/NPC or at times dragging a light-blocking wall etc. The former seems to trigger almost every time while the latter minor events only seem to occur sporadically (and maybe the combination of both DM light layer/UDL changes and player losing focus on their browser tab is required). In general, when making changes to a map while actively playing you'd be better off taking one of two steps for now unfortunately. Have players highlight their token and zoom in so they can't see much of the map, then ask them to toggle (move one square up then back down for example) as this corrects the vision in all instances we've seen. Otherwise, it may be better to move off the map you're making UDL changes to and then move back even if this breaks up the flow. I know these aren't the answers anyone wants to hear, but in some cases it can be better than exposing the full map layout or other surprise for the characters. Hope this helps for now, Joe

I have no idea why its happening all of the sudden but I, too, have the cone vision bug.&nbsp; The strange thing is I've been using UDL for a while now and I had a game two days ago where I was using night vision AND explorer mode with tons of light sources all over the map because it was in the middle of a forest fire. It was working fine.&nbsp; Today I'm building a dingy city street with some streetlamps.... cone vision bug. I'm not sure what triggered the issue. It seems the forest fire map still has circular night vision. Forest fire map has 23 light sources and works fine. City street has 15 and its busted. Same settings on both maps.&nbsp; Based on what I'm reading this is a known issue and I'm very concerned that I've seen basically no response by Roll20 about fixing it. This is a HUGE unplayable bug. I'd imagine we would be hearing more about what's being done about something like that.&nbsp;

I was told that this was an issue discovered with this update, but adding tokens to the GM layer makes them invisible when they are added to a map where other tokens with vision/nightvision are present. The token is added, but it is not visible on the GM layer specifically. Adding it to the token layer is fine, but the GM layer, which is otherwise normal, will not show tokens for me under any circumstance.

I made a forest with a bunch of circle shapes for trees and it seems the circles do not block LOS. Has anyone else experienced this? My squares and polygons work perfectly fine.

Vince P. said: I made a forest with a bunch of circle shapes for trees and it seems the circles do not block LOS. Has anyone else experienced this? My squares and polygons work perfectly fine. Circles or hand drawn lines aren't working well with the Dynamic Lightning. There is an API script available that can help if you go pro, other then that it's a no go. (Did I just rhyme?)

Circles have never worked with DL, due to how the math is done. The recommended practice is to draw a circle-like polygon. Or in the case of pillars and tree trunks, many people make small Xs. That allows the player to still see a lot of what they can't see past.

Jonathan M. said: I Finally Decided to use UDL and it was working better than ever, then after this past Saturday a hot fix was put out by Roll20 Dev team and now all my UDL work on all my maps, plus tokens is gonna have to be switched back to Legacy bc you went and broke the new lighting, its unusable now, bc now every token is auto given broken unchangeable field of vision something i never use on any token. now is auto activated and cant be changed bc its written in some weird hot fix you put out to fix this now makes it permanent unchangeable token feature. my token placed before hotfix works fine, Now any new token or player token placed turns to this. &nbsp; If this can be undone before my next session, would save me atone of redoing everything back to legacy lighting. I'm having the same issue as Jonathan M with the new UDL. I was on the legacy system until yesterday when I switched my maps over and noticed this weird issue with field of vision. In order to try to fix this I created a brand new token to see if maybe it was due to some random setting I hadn't realized was on. I set the name and permissions for hp bars and what not, then enabled UDL vision and 60ft darkvision. I set a red tint to make it easier to see the field of vision, and for some reason it only shows the map up to half of the token's darkvision distance. So my token that has 60ft of darkvision only gets 30ft of vision. These images were taken with no light sources other than a token with 60ft darkvision. The first picture is what the GM sees, the second image is what the token sees(using ctrl-L). Again, the red tint is only to make the field of vision easier to see, the glitch is present regardless of tint. I have also double checked the limited fov option, it is off, but even if I turn it on and set it to 360 degrees nothing changes.

I am also experiencing the cone light issue.&nbsp;

Bret R. said: jason the dm&nbsp; said: No. They are using you to develop their software. You've been hired to find bugs and report on them. And no you don't get paid for your work Such vitriol. If you feel so strongly about it, just don't use the system until it's ready and finished. It's really that simple. He's not wrong though... That is a very simplistic approach "Don't use the system that you pay for despite the developers saying it's ready". That's like buying a Ferrari with only three tires. "Yeah, we know you paid for the car, but if you could just not use it until we manage to get you that fourth tire that would be great"

I am experiencing the cone light issue with two -- only two -- of my players' tokens right now and it's nearly ground our game to a halt. I'm playing an underground campaign where lack of light is actually a major issue for my players and it's practically unusable. It's really upsetting that I pay a monthly fee for this right now and there doesn't seem to be a lot of dev action on it? I'd kind of hope this was Priority One since you're asserting that it's reached feature parity with LDL.&nbsp; If you need to check out a game for an example, on my account it's "As Above, So Below" and the problem tokens are Bri and Scarf. ed: sorry I know this is a recent issue but at least don't start throwing around sunsetting when there's still bugs this egregious?

I have a simple question for the devs. Is there any reason WHY Legacy Dynamic Lighting has to go? Why can't it be kept as a feature?

First, unless it has been corrected, some players notice problems when a) swapping between tabs/browser windows or b) opening another application on top of the roll20 window. This would appear to be causing some kind of render or re-render issue that exposes the entire screen to some players when they return to the roll20 window. This behavior seems to be tied to the more important second point below. In order to avoid this, have players put their roll20 window in a separate window and try to avoid opening tabbing or opening other windows/applications on top of the roll20 window. I know this isn't a good solution, but it seems to work most of the time. This solution isn't practical for those who use dndbeyond for their character sheets (the charactermancer isn't anywhere near as functional for that activity).

I am getting this joyous issue since the update. Cannot get the updated lighting to work at all now.

I am experiencing the problem too - I am going back to the old method and will NOT try the new one until it is mature +3 months, just like I treat my Microsoft releases at work. Shame to tar Roll20 and Microsoft with the same brush...

keithcurtis said: Circles have never worked with DL, due to how the math is done. The recommended practice is to draw a circle-like polygon. Or in the case of pillars and tree trunks, many people make small Xs. That allows the player to still see a lot of what they can't see past. Keith:&nbsp; I would beg to differ with you.&nbsp; Circles used to work.&nbsp; When I would put together a jail with Bars, I would draw small circles on the bars and they worked in LDL.&nbsp;&nbsp; Bob

So with UDL now at "parity" I thought I would give it ago with Roll20's own game Masters Vault.&nbsp; I did nothing else except turn it on - all other settings were turned off and this is the result...... Before turning it on - ok After turning it on.....unplayable double vision LDL turned on....perfect

I don't know if someone pointed it out already but it appears that circles don't work as Dynamic Lighting Walls. Sorry if someone already mentioned it.

Bob P. said: keithcurtis said: Circles have never worked with DL, due to how the math is done. The recommended practice is to draw a circle-like polygon. Or in the case of pillars and tree trunks, many people make small Xs. That allows the player to still see a lot of what they can't see past. Keith:&nbsp; I would beg to differ with you.&nbsp; Circles used to work.&nbsp; When I would put together a jail with Bars, I would draw small circles on the bars and they worked in LDL.&nbsp;&nbsp; Bob Let me re-phrase then: Circles above a certain size. The practice has been specifically eschewed on the Roll20 wiki &nbsp;for years (and more recently the&nbsp; Help Center ). I just didn't feel like complicating the issue with niche cases. The advice remains: don't use circles; they can cause problems.

Ravenknight said: Vince P. said: I made a forest with a bunch of circle shapes for trees and it seems the circles do not block LOS. Has anyone else experienced this? My squares and polygons work perfectly fine. Circles or hand drawn lines aren't working well with the Dynamic Lightning. There is an API script available that can help if you go pro, other then that it's a no go. (Did I just rhyme?) My previous answer would have been more helpful if I had thought to mention that yes, there is an API script that can help. It's by the Aaron (of course), available in One Click and converts circles into multi-sided polygons.

I’m usually lurking... but my UDL works perfectly every time I’ve used it for my sessions. &nbsp;Is it possible that some of these issues are stemming from updating from LDL? &nbsp;I never used LDL and didn’t convert anything as I’ve been using UDL from day one. &nbsp;It had a few sight glitches when it started a few weeks ago and it is still a bit of a memory hog (I run it off a MS Surface Go and a Brave Browser) but it’s been flawless for me. &nbsp;I’m not sure what else I could possibly be doing (I’m not doing anything advanced) because this feature has been a staple for my games for a while now and it’s awesome. Edit: For the record, I download maps and draw the Lighting lines myself using the regular-size polygon tool, if that helps. Let me know if you want me to test something on my end I’d love to help. &nbsp;

Ian C. said: I’m usually lurking... but my UDL works perfectly every time I’ve used it for my sessions. &nbsp;Is it possible that some of these issues are stemming from updating from LDL? &nbsp;I never used LDL and didn’t convert anything as I’ve been using UDL from day one.&nbsp; That's very interesting. I've always tried converting my old maps and tokens and the result have been less then stellar. Shame that starting over would require that I recreate 450+ monsters and NPCs. This mess is painful to say the least.

I wish I could just use the first UDL update. When it was just Vision/Nightvision/Bright Light/Low Light. That's all I needed. The rest is bells and whistles and its breaking everything . Why can't this be more like an API where I can just use the older version. * cries in DM * This tint color and sharpen tool stuff is EXTRA af. Its fun, but EXTRA. I just want it to be functional first.

Ravenknight said: Ian C. said: I’m usually lurking... but my UDL works perfectly every time I’ve used it for my sessions. &nbsp;Is it possible that some of these issues are stemming from updating from LDL? &nbsp;I never used LDL and didn’t convert anything as I’ve been using UDL from day one.&nbsp; That's very interesting. I've always tried converting my old maps and tokens and the result have been less then stellar. Shame that starting over would require that I recreate 450+ monsters and NPCs. This mess is painful to say the least. Yeah, I can imagine that would be a nightmare - for the record, I did accidentally delete all of my assets about a week ago and I couldn’t undo the damage with a backup.. and had to draw all the lines again. For my maps, I don’t get ANY of the problems in this thread - no bleed, no night vision issues, clipping works perfectly, drag and drop... It sucks that you guys can’t use it. &nbsp;Maybe try making a new map by scratch and seeing if it works? I can test things out too if you want me to guys!

I am looking forward to a Roll20 response to the issues raised (time and again) by&nbsp; Brian C. &nbsp; Having dim light + dim light = black means this lighting model needs some serious rethinking.