Updated Dynamic Lighting - Feedback Thread

Great !!!!

Just tried to join a pickup game with Dynamic Lighting turned on and all I could see was a black box. We tried everything that we could think of in the game. I cleared cache and tried 3 different browsers, Brave, Chrome and Edge. Couldn't even load the site on Edge, unsurprisingly. Eventually, the GM had to turn dynamic lighting off entirely. I could then see the map, but my character became completely unplayable. I couldn't control my token or adjust any settings. I subscribed hoping that would take care of it, no dice there either. And, since it's a subscription, I am just out the money. Really, really poor user experience.

Kaiju K. said: 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? As far as I can see there is no reason for them to get rid of it, aside from pushing people into using the broken UDL. It wouldn't require any additional effort on their part to keep around until UDL is finished; the only reason I can see that they are moving forward with UDL is to keep to some invisible and arbitrary deadline set by someone at Roll20's development team.

Chutzpah said: Just tried to join a pickup game with Dynamic Lighting turned on and all I could see was a black box. We tried everything that we could think of in the game. I cleared cache and tried 3 different browsers, Brave, Chrome and Edge. Couldn't even load the site on Edge, unsurprisingly. Eventually, the GM had to turn dynamic lighting off entirely. I could then see the map, but my character became completely unplayable. I couldn't control my token or adjust any settings. I subscribed hoping that would take care of it, no dice there either. And, since it's a subscription, I am just out the money. Really, really poor user experience. Sorry to hear that bud; it's about to become a very common problem by the sounds of things :I

Updated Dyanmic Lighting has never worked for me. No light sources appear, nobody can see anything. I converted everything (token and map) to updated dynamic lighting, I tried ctrl+L on player tokens only to see them in a black void. What is going on?

Building on my previous post , the loss of 5e-style darkvision seems to be the intentional change with the biggest detrimental effect to the users of the system. The other points I brought up are important as well, but this seems to affect the widest number of users. In LDL, GMs had to make a choice: have a token emit light only the controlling player could see or emit light all players could see. It appeared at first that UDL would improve on that by providing a second light source in UDL's Night Vision. Unfortunately, Night Vision is not "real" light as far as UDL is concerned. It provides bright light only, which can be differentiated through a filter or through tinting. This represents a loss of functionality for players of 5e and other game systems over what was provided previously. In LDL a GM could set a token to Emits Light 60/0 to simulate darkvision for 5e (or other game systems) as dim light. This dim light would combine with other dim light sources to create bright light. The only way to approximate dim light darkvision in UDL is to set a black tint on Night Vision. This has the effect of making overlapping dim light sources slightly darker  rather than changing the overlapping area to bright light. Night Vision needs to be a full-fledged light source that only players who control the token (and the GM) can see. Before light from the token is added to the VTT, UDL needs to check whether the player viewing the VTT has control of the token that is emitting light. Players that do not control the token should see light as they see it now, with just the Emits Light values used. Players that control the token need to have Emits Light and Night Vision combined before the light is added to the VTT. This gives a chance for the player to see dim light that combines with other bright and dim light sources as in the following examples (all assume the token has vision): Normal vision carrying a torch. Set as Emits Light: Bright 20 / Dim 20. Everyone with vision sees the torch light. Darkvision to 60 feet and no light source. Set as Night Vision: Bright 0 / Dim 60. Only controlling players with will see dim light to 60 feet. Darkvision carrying a torch. Set as Emits Light: Bright 20 / Dim 20 and Night Vision: Bright 0 / Dim 60. Controlling players see 40 feet of bright light and 20 feet of dim light. In the first 20 feet, the bright torch light overrides the darkvision. In the second 20 feet, the dim torch light combines with the dim light of the Night Vision to become bright light. The final 20 feet are only covered by darkvision and appear as dim light. Players that do not control the token only see the 20 feet of bright light and 20 feet of dim light from the torch. Warlock with Devil's Sight to 120 feet. Set as Night Vision: Bright 120 / Dim 0. The controlling players see 120 feet of bright light, and other players see nothing. If a torch was added, it would not effect players who control the token (the devil's sight bright light overwhelms it), but all other players would only see the torch light. This solution restores the lost functionality for 5e darkvision and has the light emitted by the token added only once to the VTT rather than the two passes currently used by UDL for lighting and Night Vision. Which values are used to determine the dimension and intensity of the light is determined by whether the player controls the token. It also fixes the bug with overlapping Night Vision tint fields by removing the need for dark tinting to simulate dim light.

Bringing this up again because it was ignored in the previous bug thread and it has implications for future features. The quote from Kenton came from a suggestion thread on colored Dynamic Lighting. Brian C. &nbsp;said: Kenton &nbsp;said: Hello all- With&nbsp; this week's update to Updated Dynamic Lighting , we've released a change to Night Vision which allows for a tint. While this is not specifically address this Suggestion, I wanted to bring it up so I might be able to get feedback on how this might work for the people in this thread. I really think tinting is the wrong way to go, both for UDL night vision and for colored dynamic lighting, unless it is heavily reworked from the scenario we have at the moment where two tokens with night vision completely blot out the map for the GM. In the end, both colored dynamic lighting and night vision likely should use the same underlying technology, but the tinting of UDL's night vision as it currently stands darkens what a token sees, which is the opposite of what light should do. Or maybe it would be more accurate to say that each light source is applied independently to the page. Guessing by the nature of the problems with the current implementation of UDL's night vision, it looks like each light source is being handled independently, incrementally tinting what is on the page. This is the wrong implementation for night vision as well as for colored dynamic lighting. Light sources should be blended, as in this demo. Clicking the question mark in the upper-right corner of the demo tells you how to change the type, direction, color, and intensity of the lights.&nbsp; <a href="https://corybeams.com/le/examples/#interactive_lights" rel="nofollow">https://corybeams.com/le/examples/#interactive_lights</a> All of the lights combine to present the final image. For example, magenta and green light combine to make white light. Dynamic lighting should similarly be blending all the light sources visible to a player before applying them to the page. This should happen in several stages: bright light, dim light, and night vision. Vision blocking walls can be processed once per light source for all three stages. Each light source adds the light that is visible to one of the player tokens to a light map for that portion of the vision. The bright lights combine into a bright light map. The dim lights combine into a dim light map, and any night vision is combined into a night vision light map. The light maps are then combined. Illuminated portions of the bright light map overwrite the dim light map, and the combined light map overwrites the night vision light map. This combined light map represents everything a player can currently see through all of their tokens both in color and intensity (dim vs bright). Since it represents what a token can see, it also represents what should be cleared from fog of war. A 1-bit light map can be retained between frames to represent the cleared fog of war. The page is rendered in the desaturated fog of war, the black from the fog of war is placed over that, and the combined light map is applied to the elements on the page (map, tokens, etc.) and drawn over that. This combination of elements gives us properly colored dynamic lighting and avoids problems like the dark circles at the edge of light sources and night vision that we have seen in the UDL beta. tl;dr: Lighting uses additive color mixing where the mixed colors are lighter. Mixing physical substances like paint uses subtractive color mixing, where colors get darker. <a href="https://en.wikipedia.org/wiki/Color_mixing#:~:text=When%20the%20red%20and%20green,a%20wide%20range%20of%20colors" rel="nofollow">https://en.wikipedia.org/wiki/Color_mixing#:~:text=When%20the%20red%20and%20green,a%20wide%20range%20of%20colors</a>. The light sources should be using additive color mixing, but Night Vision's tinting is using subtractive color mixing instead.

So I finally decided to bite the bullet and try the conversion tool with a marketplace product. I will post a little and then edit as I go further because of how the text editor times out. I will mark when it is completed. Here is what I found: 1. Pages with no Dynamic Lighting or AFoW. By default, every page is selected by the conversion tool, including those with no trace of LDL. This creates a problem for art pages, landing pages, encounters without Dynamic Lighting, many overland maps, etc. By turning on Dynamic Lighting on a selected map when it was not on in UDL, the page is dim for the GM, and the players cannot see anything until they get a token with vision and a light source or the GM changes the page settings again. I also ran into a case where a page did not have LDL or AFoW checked, but AFoW-&gt;Dim Light Reveals was checked. This transferred as Dynamic Lighting and Explorer Mode being on, even when both were off in LDL. 2. Third-party light sources now clear fog of war with limited success. This functionality was lost in the first rewrite of Dynamic Light, so it is nice to see it finally starting to return.&nbsp; The functionality works after a fashion. It only works for a non-GM user. It does not work for the GM with Ctrl+L, so the GM has no idea what the players can seelso, the VTT was zoomed out a bit when the screen capture was taken, so you can see the explored area not lining up with the actual map (Duplicate of the location "Dene" for instance).&nbsp; The conversion made an odd choice of giving Night Vision of 0 feet to the player token. The party token was converted well. It turned the spotlight effect that was used on the LDL page (Emits Light 50/50) into Bright 50 / Dim 0. It strikes me that setting dim light to 0 might be a way to preserve the spotlight effect noted in my earlier post . 3. DL lines of different thickness no longer line up. The secret wall juts out here. And the players cannot easily tell that there is a door here. My takeaways: The conversion tool needs to be more intelligent when first presented to a user. &nbsp; At minimum, pages that have no Dynamic Lighting should not be selected by default in the conversion tool. If they are still selected but Dynamic Lighting and AFoW are off but have sub-settings checked, those settings could transfer over while still leaving UDL off. Conversion of tokens that do not emit light is odd. &nbsp;Why do all tokens with vision that do not emit light get a Night Vision setting of 0? It seems&nbsp;superfluous.&nbsp; UDL needs to preserve its page settings when it is turned off. &nbsp;If UDL is turned off, you lose the settings. If LDL is switched back on, you can see the LDL and AFoW settings, but the page loses its UDL settings in addition to UDL being turned off. The UDL settings should be preserved so that a user can switch it back on and be back where they started. Blocking vision from the edge of DL lines really messes up games. The players cannot always tell what is going on with the walls sticking out, but they know something is odd.

The only time I ran into trouble so far was with a bought module (Forge of Fury) and when I used the conversion tool, so there may be something to what Ian proposed. (I do see those weird triangles top right when logged in as GM, but not when logged in as Player.) 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;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;

I will put Dynamic Lighting bugs I encounter in this post. 1. Token location de-syncs between player and GM at certain zoom levels. It took a while to duplicate this. If the zoom level on the player view of the VTT was zoomed out such that part of the map went off the screen, the player token sometimes moves to a different location than indicated from the GM view. Player GM 2. Walls block light strangely. This occurred in both player and GM accounts. The wall blocks light correctly when zoomed in, but it blocks strange amounts of light as you start to zoom out and continues to get worse. DL Lines 141% Zoom 99% Zoom 3. Slow Daylight + Explorer. &nbsp;Not so much a bug, just an observation. A 65 x 85 map with only a few DL lines, Daylight Mode, and Explorer Mode ran a bit slow with a single token with vision. With Daylight Mode off and using the token's Night Vision, response times were much better.&nbsp;

Providing him a link PLZ&nbsp; &nbsp; &nbsp;:)

Brian C. said: Building on my previous post , the loss of 5e-style darkvision seems to be the intentional change with the biggest detrimental effect to the users of the system. The other points I brought up are important as well, but this seems to affect the widest number of users. In LDL, GMs had to make a choice: have a token emit light only the controlling player could see or emit light all players could see. It appeared at first that UDL would improve on that by providing a second light source in UDL's Night Vision. Unfortunately, Night Vision is not "real" light as far as UDL is concerned. It provides bright light only, which can be differentiated through a filter or through tinting. This represents a loss of functionality for players of 5e and other game systems over what was provided previously. In LDL a GM could set a token to Emits Light 60/0 to simulate darkvision for 5e (or other game systems) as dim light. This dim light would combine with other dim light sources to create bright light. The only way to approximate dim light darkvision in UDL is to set a black tint on Night Vision. This has the effect of making overlapping dim light sources slightly darker &nbsp;rather than changing the overlapping area to bright light. Night Vision needs to be a full-fledged light source that only players who control the token (and the GM) can see. Before light from the token is added to the VTT, UDL needs to check whether the player viewing the VTT has control of the token that is emitting light. Players that do not control the token should see light as they see it now, with just the Emits Light values used. Players that control the token need to have Emits Light and Night Vision combined before the light is added to the VTT. This gives a chance for the player to see dim light that combines with other bright and dim light sources as in the following examples (all assume the token has vision): Normal vision carrying a torch. Set as Emits Light: Bright 20 / Dim 20. Everyone with vision sees the torch light. Darkvision to 60 feet and no light source. Set as Night Vision: Bright 0 / Dim 60. Only controlling players with will see dim light to 60 feet. Darkvision carrying a torch. Set as Emits Light: Bright 20 / Dim 20 and Night Vision: Bright 0 / Dim 60. Controlling players see 40 feet of bright light and 20 feet of dim light. In the first 20 feet, the bright torch light overrides the darkvision. In the second 20 feet, the dim torch light combines with the dim light of the Night Vision to become bright light. The final 20 feet are only covered by darkvision and appear as dim light. Players that do not control the token only see the 20 feet of bright light and 20 feet of dim light from the torch. Warlock with Devil's Sight to 120 feet. Set as Night Vision: Bright 120 / Dim 0. The controlling players see 120 feet of bright light, and other players see nothing. If a torch was added, it would not effect players who control the token (the devil's sight bright light overwhelms it), but all other players would only see the torch light. This solution restores the lost functionality for 5e darkvision and has the light emitted by the token added only once to the VTT rather than the two passes currently used by UDL for lighting and Night Vision. Which values are used to determine the dimension and intensity of the light is determined by whether the player controls the token. It also fixes the bug with overlapping Night Vision tint fields by removing the need for dark tinting to simulate dim light. Agreed on all points.

The singular fact that "ctrl + L" doesn't work with UDL, to preview my player's vision is a deal breaker. Reloading into player view is far too cumbersome. Edit: I tried another test map and it works now, I'm thinking order of operators mattered in how I setup the lighting? Regardless the "ctrl + L" preview doesn't work like the old version, I still see too much GM info during the preview, I literally want to see what my players will see and nothing else.

Nicholas said: Dustin D. said: The singular fact that "ctrl + L" doesn't work with UDL, to preview my player's vision is a deal breaker. Reloading into player view is far too cumbersome. Hey Dustin -&nbsp; As I mentioned to Michael D. above, Ctrl + L should be working as expected right now - can you provide me a link to the game in which you noticed it was working and the name of the page as well, please? Thank you in advance! :) Maybe I'm using it wrong, but this is how the UDL preview works for me now. Note in the old version I can't see the rest of the field or the building.&nbsp; If this is intended than this is poor decision and "not" feature parity. LDL: &nbsp;&nbsp;&nbsp; UDL:

Nicholas said: Chutzpah said: Just tried to join a pickup game with Dynamic Lighting turned on and all I could see was a black box. We tried everything that we could think of in the game. I cleared cache and tried 3 different browsers, Brave, Chrome and Edge. Couldn't even load the site on Edge, unsurprisingly. Eventually, the GM had to turn dynamic lighting off entirely. I could then see the map, but my character became completely unplayable. I couldn't control my token or adjust any settings. I subscribed hoping that would take care of it, no dice there either. And, since it's a subscription, I am just out the money. Really, really poor user experience. Hi&nbsp;Chutzpah - Can you provide me a link to that game, the name of the page, and the name of the character in the Journal these issues occurred with, please? I definitely want to take a look and see what might have happened. Thank you for the feedback on this! Here's the link to invite: [redacted] Character name is the same as mine, not sure of name of the page as I wasn't running the game. When we started playing, all I could see was a big black box and no map. Zooming out just centered the black box. The GM turned off Dynamic Lighting, at which point, I could see the map, but then lost control of my character. You may see some duplicates as we tried importing the same character from another game that I am playing, as well. Also, the GM tried quite a few things to try and troubleshoot on his end, including turning me into an NPC and back.

As a point of order, does roll20 not have a way to internally track users ---&gt; games? The majority of replies from devs in this and the previous thread (and the one before that ) have all been "can you provide a link to the game".

I have nearly a hundred games. A dev could not tell which one I was referencing from a screen shot.

Brian C. said: Building on my previous post , the loss of 5e-style darkvision seems to be the intentional change with the biggest detrimental effect to the users of the system. The other points I brought up are important as well, but this seems to affect the widest number of users. Just adding an AMEN to this... to everything that Brian said regarding UDL "darkvision," which is not darkvision at all.

PublishedAuthor said: The only time I ran into trouble so far was with a bought module (Forge of Fury) and when I used the conversion tool, so there may be something to what Ian proposed. (I do see those weird triangles top right when logged in as GM, but not when logged in as Player.) 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;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; That could be one issue - I have never played a module on Roll20 with pre-drawn stuff, or converted an old map.&nbsp; I have become super fast at drawing new lines pretty easily.

Nicholas said: Hey&nbsp;Paul N. -&nbsp; Would you mind providing me a link to the game in which this occurred, please? We'll definitely review it as soon as possible. Thanks for the feedback here! Here you are...... <a href="https://app.roll20.net/campaigns/details/6751836/borderlands-and-beyond" rel="nofollow">https://app.roll20.net/campaigns/details/6751836/borderlands-and-beyond</a>

Chutzpah said: *Snip* Hi&nbsp;Chutzpah - Can you provide me a link to that game, the name of the page, and the name of the character in the Journal these issues occurred with, please? I definitely want to take a look and see what might have happened. Thank you for the feedback on this! Here's the link to invite: ************ Character name is the same as mine, not sure of name of the page as I wasn't running the game. When we started playing, all I could see was a big black box and no map. Zooming out just centered the black box. The GM turned off Dynamic Lighting, at which point, I could see the map, but then lost control of my character. You may see some duplicates as we tried importing the same character from another game that I am playing, as well. Also, the GM tried quite a few things to try and troubleshoot on his end, including turning me into an NPC and back. As a rule, never &nbsp;publicly post a join link to a game. Anyone who sees that link can now jump into that game and cause mischief. The game creator should change the join link ASAP. Posting the url of the landing page of the game is sufficient for Roll20 to locate the game. They can either copy the game or can enter it without the join link from there.

I'm having a diverse set of issues with Updated Dynamic Light on one of the maps in the Hidden Shrine of Tamoachan module for D&amp;D 5E. I have reported the bug in more details here: <a href="https://app.roll20.net/forum/permalink/9094354/" rel="nofollow">https://app.roll20.net/forum/permalink/9094354/</a>

I was told I should post my bug complaints on this thread to provide more data for the developers to work with. Copypasted: "Has anybody figured out a way to get Night Vision to work on tokens again? Currently its fixed to 90 degree Field of View on my brand new campaign that has never had any other settings or FOV enabled. I've been fiddling around with settings open to find a way to over-ride whatever setting is doing this, but with no success. The issue also seems to trigger when I activate low level lighting for tokens, although for some tokens its fine but if I copy and paste them, they start to glitch as well" I also noticed a similar issue with Dim Light, where activating the option fixes bright light in a 90 degree FOV, facing South-East. So after a lot of experimenting, it seems some element of Night Vision and Dim Light are triggering a FOV limitations. Hopefully that narrows it down a bit. The Campaign name is The Lost City of Thunderhorn, and I didn't start putting assets into it or messing around with Dynamic lighting until maybe Sunday or Monday. (so 4 or 5 days ago). I'll make a separate map where I can reproduce the bug and title it "Dynamic Lighting Bug Demonstration". Any chance I can get a time frame on when this will be fixed? It basically means I can't use the lighting features at all.&nbsp; EDIT: Okay I solved it. Basically, you just have to transfer everything over to a new map and it solves the issue. So my diagnosis is that something gets 'stuck' on the map instance and once it breaks, it remains broken like that and screws up all the dynamic lighting for that page. It doesn't take too long to move everything over so this is a reasonable short term solution until the bug is fixed. Just avoid fiddling around with the settings too much as some combination of things must trigger this.

Not sure where to ask this - i have a 'backer' account and have access to dynamic lighting - will i get updated dynamic lighting? (i cant check in my account as i was gifted a 3 month PRO upgrade by Paizo)

Hello Everyone, I know i have seen this issue pop up before but i can't seem to find if there was a fix.&nbsp; One of my players tokens is able to see the entire map (where it is lit) as if they had been there (using explorer mode). Any thoughts?&nbsp;

Do does the fact you're no longer bringing in missing features means we’ll never see the dim light Darkvision/bright crossover with other dim light since it is not there already?...

Nicholas said: Zeragamba said: 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: Hey&nbsp;Zeragamba -&nbsp; Would you mind providing me a link to the game in question, please? I'll definitely further review with our team! here's my game:&nbsp; <a href="https://app.roll20.net/campaigns/details/6953987/the-archive" rel="nofollow">https://app.roll20.net/campaigns/details/6953987/the-archive</a> &nbsp; Though looking it at today, my issues seem to be resolved.

Nicholas said: 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; Hey&nbsp;PunyPaladin -&nbsp; Can you provide me a link to this game, the name of the page, and the name of the characters Token/Journal entry this occurred with, please? We'll definitely take a closer look at what might be going on here. Thanks for the report!&nbsp; PM Sent

Nicholas 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. I had experimented a little with UDL back in April, but after some frustration I decided to stick with LDL.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; Or any page as it turned out.&nbsp; 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.&nbsp; The token issue persisted. I eventually realized that the Conversion Tool had corrupted the default tokens for every token in the game.&nbsp; It was possible to get them working again by deleting the existing default token and setting a new one.&nbsp; 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?&nbsp; 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?&nbsp; 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.&nbsp; 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.&nbsp; Am I missing anything important? Thanks for the help Jamie Hey&nbsp;Jamie.- Would you mind confirming for me the exact name of the page you converted in your game? Also, can you tell me the names of some of the default tokens in which you for sure know the issue occurred with, please? Thank you for the report on this! I've already fixed my main campaign by hand, but I just tried reproducing the problem on a copy and the same problem occurred.&nbsp; Here are the details: Link to the relevant landing page:&nbsp; <a href="https://app.roll20.net/campaigns/details/8335323/curse-of-strahd-testing-udl" rel="nofollow">https://app.roll20.net/campaigns/details/8335323/curse-of-strahd-testing-udl</a> The page I converted is named "Blizzard Cave". It's a custom map that I created within the purchased Curse of Strahd module. I deselected the "Convert Journal Entries" option and deselected all other pages. I noticed issues with PC tokens (eg. "Akra", "Gnarsh", "Sai") as well as NPC / Monster tokens (eg. "Arabelle", "Arrigal", "Acolyte", "Animated Armor") If it matters, the original landing page that encountered issues is&nbsp; <a href="https://app.roll20.net/campaigns/details/8290822/curse-of-strahd" rel="nofollow">https://app.roll20.net/campaigns/details/8290822/curse-of-strahd</a> .&nbsp; I have since disabled UDL on the page I converted the first time around (also "Blizzard Cave") and replaced the default tokens for every character.&nbsp; I did notice in the conversion tool that it recognized that the "Blizzard Cave" page had already been converted. Let me know if you need any other details Jamie

Drespar said: Hi everyone! First off, thank you for your continued reports and discussion of this topic, it is important for us to have feedback from all of you so we can properly prioritize and plan. We are going to provide a more in depth post to engage with you on other reported concerns before the end of the week. However, we did want to provide some insight into what we are currently working on, including two of your reported issues: Vision/Lighting appearing as a cone without directional light being active We are still investigating this issue but believe we are nearing a solution. Please keep reports coming in to make sure we are finding commonalities and root causes. Performance improvements for explorer mode We are diving into additional optimizations that can be made to explorer mode to improve performance for everyone by better accounting for hardware based size limits. Diagnosing issues connected to Zoom I sent you a message with details on issue #1

Drespar said: Also, another quick update! (seemed&nbsp;more fitting in a smaller separate post) The dev team has been working with the forced field of vision issue that many of you are experiencing and we have a fix in the works! Keep an eye out for updates next week in the release notes and we will also let you know here. Drespar, What is being done to address the massive memory leak that started right around the time of the release? I'm reluctant to say it was caused by the release simply because I can't confirm it, but the timing is rather suspect.

Nicholas said: Peter said: Nicholas, Thank you for looking into this :) It happens on a completely new game with no extra assets loaded. To reproduce. 1. Create New Game; give it a name; Launch Game 2. On settings for the default/first page, enable Updated Dynamic Lighting and Explorer Mode - no other changes 3. Zoom out until whole page visible.&nbsp; Notice the triangles and how they change as you scroll in and out (see first screenshot below) 4. Drop a token onto the page in the top 'lit' area (middle top) ; give yourself control; give the token Vision but no light. 5. Re-join as Player; Black screen 6. Scroll out; Notice the extra lit areas appear; scroll in and out and see how they change (see second screenshot below) If a map layer is present then it will be revealed where these 'triangles of light' are present. icholas said: Peter said: Revealable Areas is completely broken on UDL. Large triangle-shaped chunks of map are revealed to players as if brightly lit.&nbsp; One of these triangles originates near top left and spreads out and widens to the right; the other originates lower down on the left hand side.&nbsp; I posted pictures before in the other thread (page 19). Please advise when this will be fixed.&nbsp;&nbsp; It is trivial to demonstrate the bug to yourselves: 1. create a new page with UDL on and Explorer mode on. 2. On that page, select Hide Areas Tool; Rectangle and drag a square across the entire page. 3. Drop a token on the page and give yourself control of it; set 'Has vision' and a 10ft bright light for the token 4. Drag your player icon to the page and Re-join as player. 5. Zoom out, notice that two large triangles are revealed to player, even before they move. This broken behaviour happens on both Firefox and Chrome current versions Thanks. Hey Peter -&nbsp; I'm actually having a hard time reproducing this on my end. Would you mind providing me a link to the game and the name of the page in which you experienced this, please? It will be a little easier for me to review at that point. Thank you! Hey Peter -&nbsp; Would you mind giving me a brief rundown of the hardware you are using? Are you using some sort of laptop, or a desktop without a GPU perchance?&nbsp; Nicholas - I've got Windows 10 Pro 10.0.19041; problem happens in both Firefox and Chrome. Hardware is HP Envy 17 Notebook PC, SKU is L0M09EA#ABU Intel core i7-5500 12GB RAM; Display answers as NVIDIA&nbsp; GeForce GTX 850M with 1Mb. Driver for display is up-to-date See <a href="https://www.notebookcheck.net/NVIDIA-GeForce-GTX-850M.107795.0.html" rel="nofollow">https://www.notebookcheck.net/NVIDIA-GeForce-GTX-850M.107795.0.html</a> Hope that helps :)