UDL 1.0 Updates, Bugs, & Feedback

I can't answer to your specific problem, since I haven't encountered it, but you can save yourself a lot of hassle by setting up the tokens exactly the way you want them and then (as the very last step) saving them as the default tokens for the character. They will come out with the settings you set, every time. The biggest mistake people make is thinking that the default token is a continuing back and forth link. That if you change the default token on the table top it will reference back and make those changes on the one attached to the sheet. Setting a default token is akin to saving a file to your hard drive. If you open a file, change it and close without saving, the next time you open it you will get the same file as the last time you actually saved. At any rate, try it and see if it doesn't help your issue to drag them fresh from the journal tab to the new map, rather than copy and paste.

Thank you. I'll give that a try next time.

Here's a video if you like following info that way: Roll20TnT Linking Tokens and Journals

TheWebCoder said: Be warned, fellow users who buy stuff from Roll20: UDL will be part of the main product patch for your product, if it's not already. Sure glad I read the notes and didn't hit update. Honestly, I can't even. So I have a game where I am using LDL, I thought i would try to see if this patch updated my game to UDL or if it would just update the products i've already brought to be UDL ready for when i am happy to turn this on.  The patch updated the maps for those games and turned off LDL on those maps.  I have no problem with a patch making a product UDL ready but it should not switch off LDL unless i ask it to.  Maybe this is something that could be looked at in what little time LDL has left?   **EDIT** < just to add to this, updating the product hasn't updated the game or converted it into only using UDL, just the maps associated with the module you have brought.

Seems to make a joke however of saying all the old features are present. I wouldn't mind then if they were honest and just said that they have 'all the core features except....X and Y' Vince M. said: Corey J. said: Happy Friday Folx!  I’m here to give a rundown of the current status and where everything is in our efforts to keep you in the know on UDL. I have been very vocal about how unhappy I am with roll20 development and communication (and in the eyes of roll20 too vocal...).  I also feel that little progress should, however, be acknowledged. Such an overview was sorely missed and gives some accountability to what is going on. So - as little this is - I am happy about it. (Brian should still check it for missing items and mistakes :-D ) Yet, I still encourage roll20 to become realistic. Given their past track record, it is impossible that all of this will be fixed by the current LDL sunset date.  Do the right thing and sunset LDL only once all these UDL issues have been fixed.  Both the devs and us will sleep better after that announcement... (and if you surprise us by it being done on time, nothing is lost...)

keithcurtis said: I can't answer to your specific problem, since I haven't encountered it, but you can save yourself a lot of hassle by setting up the tokens exactly the way you want them and then (as the very last step) saving them as the default tokens for the character. They will come out with the settings you set, every time. [snip] At any rate, try it and see if it doesn't help your issue to drag them fresh from the journal tab to the new map, rather than copy and paste. I wanted to report that on a quick off-session test, this did prevent the complete UDL breakage that I've been experiencing for so long, so thank you for the alternate means of player token placement for my UDL maps. Our next session is two weeks away, and I will give it a more reliable acid test then. Thank you for the suggestion.

I don't think Roll20 is setup to load in all of the UDL settings but keep them disabled, and allow us to keep using LDL. There's also been a bunch of bugs reported if LDL and UDL information are both present. I play in another game, Frostmaiden, and that DM switched over to UDL. We spend at least one hour per game asking who can see what, or if we can hear each other over Roll20 audio. The minute I play in that game and it runs fine, I'll be all for testing UDL again; but for now I'm not spending hours debugging my game and having to implement workarounds. That's why I was annoyed that a product patch tried to flip the switch on me. Iaurcair said: So I have a game where I am using LDL, I thought i would try to see if this patch updated my game to UDL or if it would just update the products i've already brought to be UDL ready for when i am happy to turn this on.  The patch updated the maps for those games and turned off LDL on those maps.  I have no problem with a patch making a product UDL ready but it should not switch off LDL unless i ask it to.  Maybe this is something that could be looked at in what little time LDL has left?   **EDIT** < just to add to this, updating the product hasn't updated the game or converted it into only using UDL, just the maps associated with the module you have brought.

keithcurtis said: I can't answer to your specific problem, since I haven't encountered it, but you can save yourself a lot of hassle by setting up the tokens exactly the way you want them and then (as the very last step) saving them as the default tokens for the character. They will come out with the settings you set, every time. The biggest mistake people make is thinking that the default token is a continuing back and forth link. That if you change the default token on the table top it will reference back and make those changes on the one attached to the sheet. Setting a default token is akin to saving a file to your hard drive. If you open a file, change it and close without saving, the next time you open it you will get the same file as the last time you actually saved. At any rate, try it and see if it doesn't help your issue to drag them fresh from the journal tab to the new map, rather than copy and paste. Very helpful - thanks!

Iaurcair said: TheWebCoder said: Be warned, fellow users who buy stuff from Roll20: UDL will be part of the main product patch for your product, if it's not already. Sure glad I read the notes and didn't hit update. Honestly, I can't even. So I have a game where I am using LDL, I thought i would try to see if this patch updated my game to UDL or if it would just update the products i've already brought to be UDL ready for when i am happy to turn this on.  The patch updated the maps for those games and turned off LDL on those maps.  I have no problem with a patch making a product UDL ready but it should not switch off LDL unless i ask it to.  Maybe this is something that could be looked at in what little time LDL has left?   **EDIT** < just to add to this, updating the product hasn't updated the game or converted it into only using UDL, just the maps associated with the module you have brought. Question-I'm curious if anyone know the answer to this question please. :)  I clicked on the patch notes for Volo's Guide: Maps and Tokens.  If I update my game to have this patch, will this convert my games to UDL? I do not want to update to UDL at this time.  This is what it says. " This content has been patched to include Updated Dynamic Lighting. All relevant settings have been applied and Updated Dynamic Lighting has been turned on where applicable." It appears that only the Volo's content will be updated- and I only use the tokens- but want to be sure before I update all of my maps without wanting to. Also- question for Roll20- if I don't update, will I be forced to update to this patch before sunset? I just need to prepare myself for this in advance if it's going to happen.

Hey, so where are we on the relationship of UDL and animated tokens not working? I know I've brought it up here and in other dedicated threads, but it's pretty clear to me that it's related to UDL. Turn off UDL, no issues. Turn it on, animated tokens only work for half a second when clicked on or is "ghosted". Move said token outside the view of something that has darkvision - works great again. Not that I want to see another issue added this laundry list of bullet points that is the UDL plague, but as a marketplace creator that deals exclusively in animated tokens, it has absolutely affected my sales.

Erica said: Iaurcair said: TheWebCoder said: Be warned, fellow users who buy stuff from Roll20: UDL will be part of the main product patch for your product, if it's not already. Sure glad I read the notes and didn't hit update. Honestly, I can't even. So I have a game where I am using LDL, I thought i would try to see if this patch updated my game to UDL or if it would just update the products i've already brought to be UDL ready for when i am happy to turn this on.  The patch updated the maps for those games and turned off LDL on those maps.  I have no problem with a patch making a product UDL ready but it should not switch off LDL unless i ask it to.  Maybe this is something that could be looked at in what little time LDL has left?   **EDIT** < just to add to this, updating the product hasn't updated the game or converted it into only using UDL, just the maps associated with the module you have brought. Question-I'm curious if anyone know the answer to this question please. :)  I clicked on the patch notes for Volo's Guide: Maps and Tokens.  If I update my game to have this patch, will this convert my games to UDL? I do not want to update to UDL at this time.  This is what it says. " This content has been patched to include Updated Dynamic Lighting. All relevant settings have been applied and Updated Dynamic Lighting has been turned on where applicable." It appears that only the Volo's content will be updated- and I only use the tokens- but want to be sure before I update all of my maps without wanting to. Also- question for Roll20- if I don't update, will I be forced to update to this patch before sunset? I just need to prepare myself for this in advance if it's going to happen. The patch only updates things relevant to that module. after i had updated mine i logged onto a second account that I use to see what the players can view and they couldn't see anything as their tokens aren't set up for UDL.  So I just clicked a few buttons on each map in that module to turn back on the LDL and they could see again.  at least that has been my singular experience with it, I can't guarantee that this is normal.

Christopher K said: Hey, so where are we on the relationship of UDL and animated tokens not working? I know I've brought it up here and in other dedicated threads, but it's pretty clear to me that it's related to UDL. Turn off UDL, no issues. Turn it on, animated tokens only work for half a second when clicked on or is "ghosted". Move said token outside the view of something that has darkvision - works great again. Not that I want to see another issue added this laundry list of bullet points that is the UDL plague, but as a marketplace creator that deals exclusively in animated tokens, it has absolutely affected my sales. Interesting issue, I do run animated tokens as well and I do not have this issue in my full UDL games. Maybe worth a support ticket with your specific game information and the tokens you use? Because it may be new or it may have another reason than UDL. Interesting issue. I also run animated tokens often and in my full UDL games I do not experience this issue at all. The reason may not be UDL related? Worth a support ticket for sure so you can give the full game and token information and they can look into it. 

Wil said: Christopher K said: Hey, so where are we on the relationship of UDL and animated tokens not working? I know I've brought it up here and in other dedicated threads, but it's pretty clear to me that it's related to UDL. Turn off UDL, no issues. Turn it on, animated tokens only work for half a second when clicked on or is "ghosted". Move said token outside the view of something that has darkvision - works great again. Not that I want to see another issue added this laundry list of bullet points that is the UDL plague, but as a marketplace creator that deals exclusively in animated tokens, it has absolutely affected my sales. Interesting issue, I do run animated tokens as well and I do not have this issue in my full UDL games. Maybe worth a support ticket with your specific game information and the tokens you use? Because it may be new or it may have another reason than UDL. Interesting issue. I also run animated tokens often and in my full UDL games I do not experience this issue at all. The reason may not be UDL related? Worth a support ticket for sure so you can give the full game and token information and they can look into it.  Animations stop moving in areas where night vision overlaps.  They advance a frame or two every time you click, but otherwise freeze.  Not sure if that's the *only* issue with animations.  But it's definitely one of them and is UDL related.

I am experiencing EXTREMELY slow scrolling, movement, etc with Dynamic Lighting since Sunday.  I’m aware that this is part of known issues caused by low graphical rendering performance issues. Except that we played on Sunday and had ZERO issues. Today this is unplayable and hard for me to edit. If I remove ALL dynamic lighting the issue is resolved. I checked out the other maps and ALL maps with dynamic lighting have this issue. But I don’t want to remove the Dynamic Lighting for when we play for a few reasons: 1) I put a lot of work into the dynamic lighting for this map (and many others) so my players don’t see EVERYTHING, specifically a locked room that they need a key to enter. 2) I pay for Pro mostly for dynamic lighting. 3) It was working perfectly less than TWO days ago.

Interaction with text boxes bugged while UDL is enabled 1. Start with a map that doesn't have any dynamic lighting enabled. 2. Create some text, and make sure you can interact with it fine (move, rotate, etc.).&nbsp; I only tested on the object/token and gm layers. 3. Enable UDL. 4. The handle to rotate the text is present but no longer functions, rotating while holding e is unreliable, attempting to move the text may randomly rotate it, and the entire map page may start moving along with your cursor. 5. Disable UDL, and functionality will remain impacted. 6. Refresh the page, and normal functionality returns (or at least it did for me). This came up while trying to duplicate issues brought up in this post: <a href="https://app.roll20.net/forum/post/9988366/text-boxes-not-working-after-update" rel="nofollow">https://app.roll20.net/forum/post/9988366/text-boxes-not-working-after-update</a> Probably the same problem in this one, I didn't think about whether UDL was enabled or not when I tested and posted there: <a href="https://app.roll20.net/forum/post/9987158/unable-to-rotate-paintbrush-drawings-and-text/?pageforid=9987231#post-9987231" rel="nofollow">https://app.roll20.net/forum/post/9987158/unable-to-rotate-paintbrush-drawings-and-text/?pageforid=9987231#post-9987231</a>

I don't feel the need to list the issues I have with UDL except to say it is not working. Many others have already highlighted the issues I'm running into so there is no need to restate them. I simply ask that you do not sunset LDL until such time that UDL is fully functional. Any statement that it is fully functional is simply not true at this time. I have been a member for 7 years and a pro subscriber for the majority of that time, but sunsetting LDL preemptively may force me to seek a more stable platform.

Eric M. said: sunsetting LDL preemptively may force me to seek a more stable platform. I second that. I like Roll20: the asset management is quite primitive, but everything else works well enough, and the marketplace has fantastic support for official modules which saves me a bunch of time, which has always been my main reluctance to switch over to another platform. I'm sticking with LDL until such time as the bugs have been worked out of UDL. But if I am forced to use a broken application, I will be switching. It's the cardinal rule of software development, and Roll20 you are about to break it: don't sunset the old feature until the new one is working at least as good.

I can reproduce Kraynic's experience exactly. (Firefox.) The behavior cropped up along with the April 13th update. #4 is particularly disruptive: 4. The handle to rotate the text is present but no longer functions, rotating while holding e is unreliable, attempting to move the text may randomly rotate it, and the entire map page may start moving along with your cursor. The textbox may also become "sticky", to use another user's phrase, and start to relocate itself without dragging. (With UDL turned on, if you either left-click or right-click somewhere else on the map, on any layer, after you have clicked on a textbox once, the textbox will teleport to that spot.) In general, the left and right mouse buttons don't function as expected once you have interacted with a textbox on a page that has UDL turned on. i.e., Text boxes + UDL = mouse-traps. The only fix that I have found is to refresh the browser and avoid all interactions with textboxes on UDL pages. Edit: Thank you for squashing this bug quickly, Devs!

Wil said: Interesting issue. I also run animated tokens often and in my full UDL games I do not experience this issue at all. The reason may not be UDL related? Worth a support ticket for sure so you can give the full game and token information and they can look into it.&nbsp; Sean G. called it out for me, but yeah, when an animated token crosses into something that has nightvision, it just stops or advances frames but only when clicking on and off of them. I'd lay money on it being UDL related.

Feel the same way as the posters above me. We finished our Rotrl campaing on free and will begin a Skull and Shackles and decided to go plus for dynamic lighting. I couldn't even get a simple tavern map properly working in UDL. LDL seems to work just fine. Do not sunset it yet. As for the issue I am experiencing I made a report, but the more I fiddled around UDL the more I managed to pinpoint the crux of the issue I am running into. So let me explain it here: I set a tavern map and put dynamic lighting barriers. On dynamic lighting layer as walls I have one big poly line that covers the walls and one line that covers the door. I have illuminated the map with dimlight light sources (torches) on proper places at dynamic lighting layer. Then I put the character token, log in to character and make a tour around the perimeter tavern. If I move slow I got no problems my character's vision is limited to what the token can see. That means once I complete the tour I cannot see other side of the building. Things get messy when I use keyboard to move swiftly around the tavern. Sometimes the game stutters. When that happens what I THINK is happening is: A clone of my characters vision gets stuck at that point. Even if I move around the building I still keep getting vision from that same spot. This happpens regardless of exploration mode on or off. Edit: Interrestingly this does NOT happen with Ctrl-L. Only when the token is controlled by the player. I also get the "screen reveal" bugs all the time. I get none of these issues when I use LDL and it is significantly faster than UDL. Bottomline is: Do not sunset LDL yet. It will cause you to lose money.

I just ran a one-on-one rogue city adventure last night and had to abandon UDL...&nbsp; &lt;ctrl-L&gt; view was exactly as it should be but player saw nothing but a black screen.&nbsp; I went through every step I know for debugging that worked in the past: player token on right map and right layer, player has token control, vision turned on &amp; nightvision 60/red tint/sharpen..&nbsp; Had the player exit the game, close the browser and reenter, and still black screen.&nbsp;&nbsp; I could confirm player control because they could move the token and otherwise act normally but saw nothing.&nbsp; Page was set with Dynamic lighting, Explorer mode off, daylight made no difference either way, and the only walls on the dynamic lighting layer was just a building with its outside walls and a door. Very hard to reproduce since both ctrl-L and "reenter as player" showed the scene correctly - I'll be setting up a test account to reproduce shortly but very disappointing to have to run an nighttime adventure that depends on limited range of vision with an entirely lit map because the alternative is completely black.

Bug Report (and reproduction steps) - Turning on UDL on a page can create a fully-black view for players on a different page. Create a new game On the Start page (which has Updated Dynamic lighting off by default), create a token with UDL Vision turned On but no darkvision or lightsource Create a new character Test and assign the token as the default token, and assign to Test player account Have Test player account log in - they arrive on the blank start page and have full control of the token Create a New page Drag the Test character onto New page (creating another token instance) in lower right corner (Note that Test player is still on Start page, which is blank and white, with control of their token on that page) Go to the page controls for New page, and turn on Updated Dynamic Lighting and Explorer mode Listen to the Test player scream as the Start page goes completely black- despite having UDL turned off. Screenshots showing the problem follow - please reproduce - message me if you have any issues doing so - and then promptly address.&nbsp; Transitive lighting effects being applied to other pages simply because there's token affiliation is rather sub-optimal and might explain some of the "black page" reports that you are receiving...&nbsp; Thanks! GM on Start Page with Test Character Test Player sees white blank Start page with Test Character token GM makes new page (Untitled), drags Test character to lower corner to create token there, and then turns on UDL At which point the Test player (still on Start page) sees entire screen go black, although settings for that page haven't been touched...

Hey everyone! We appreciate you continuing to bring issues to our attention. Thanks to your reports, we have just pushed two fixes that I'd like to tell you about: 1. We have released a fix for the reported problems regarding text boxes not working correctly in UDL. 2. We have released a fix for an issue where low light distance was being calculated from the center of a token even when bright light was also present, causing dim light and bright light to overlap. Please let us know if you continue to have problems in these areas. The team is hard at work resolving as many of these issues as we can, and we appreciate your patience. Thanks so much!

Hi everyone!&nbsp; We heard your feedback and understand your frustrations about the game patching and UDL. We want to be sure we provide as much clarity as possible so below you will find more information about the issues you’ve raised: The UDL update should be separate from game patches. This is a technical limitation, as the only way we can modify game data is through patches. In this case, it was crucial to patch our Marketplace products to ensure users have the best experience with UDL as we transition toward the LDL Sunset. However, based on your feedback, we’re working on improved Help Center documentation that will explain game patching in further detail. I’ve patched my game with the UDL patch, and now I want to revert to LDL. If this is something you’d like to do, you absolutely can. Our patching did not remove or modify the LDL settings; we simply added the UDL settings and switched UDL to on. You can switch Legacy Lighting back on via the page settings menu.&nbsp; Following the steps below to turn it on: In the Dynamic Lighting tab, set Dynamic Lighting to “off.”&nbsp; Then, in the Legacy Lighting Tab, check Dynamic Lighting to "Enabled" and toggle on the "Enforce Line of Sight" setting.&nbsp; You can see these steps above right here: While we work towards providing full support for Updated Dynamic Lighting, it was crucial that we updated our “pre-2021” Marketplace items to utilize the Updated Dynamic Lighting features. As items continue to undergo this conversion process, we wanted to make it clear that you still have the option to use LDL if you like.

These April 15 hotfixes seem very helpful from my perspective. The one regarding light sources was a major nuisance for me, and I'm very pleased to see it fixed. I would like to add another pair of bugs to the list; it may be that these have been captured in one of the queued items in&nbsp; <a href="https://app.roll20.net/forum/permalink/9741240/" rel="nofollow">https://app.roll20.net/forum/permalink/9741240/</a>, &nbsp;but I don't know for sure. I am posting here so that other users may be able to corroborate my observations, and so that people can use this narrative for workarounds when they find bugs in their own games. If Roll20 staff could please shed some light on the matter, I'd be willing to log one or both of these as support tickets. If they are already covered under an existing ticket, I don't see the point. The first bug is definitely a bug; something is broken. The second "bug" is mostly a bug in the sense that it doesn't behave consistently and leads to confusion as a result, and it reveals an avenue for major improvement going forward. First Bug: Let's say that I place a token on the map, set to emit Bright Light to 20 ft. and Dim Light to 20 ft. When a second token is placed on the map, granted vision, and saved, it "sees" this light source appropriately. If this second token is subsequently edited and its Light Multiplier value is changed to a value greater than 100% (let's say it's set to 200%), its vision of the Bright Light updates appropriately, such that it "sees" a Bright Light of radius 40 ft. Its vision of Dim Light does not update appropriately, so it appears as if there is a Bright Light radius, but no Dim Light at all. A page refresh does not remedy this error. But if the light-emitting token is moved even slightly, the Dim Light radius snaps into existence. If a saved token which emits light is dragged from the Journal after the Light Multiplier is edited, its Bright Light and Dim Light render appropriately. I have verified this bug in both Firefox and Chrome, using a dummy player account. This bug does NOT manifest when decreasing Light Modifier, whether from 200% to 100% or from 100% to 50%. It only manifests when Light Multiplier INCREASES. This bug also manifests if two tokens, both controllable by the same player, but with differing Light Multipliers, are dragged onto the map. In this case, the bug again manifests if the second token has a larger Light Multiplier than the first, but not when the first token's multiplier is the larger one. Workaround: The best way to work around this bug is to use a blank map to set up any new player tokens with vision properties that include a Light Multiplier that isn't the standard 100%, and save them in your Journal. Drag them from there into onto the actual map you intend to use. Start with the token(s) with the largest Light Multiplier first. If at all possible, avoid adding any tokens thereafter with a Light Multiplier larger than the largest you are already using. If your map already has lights on it, then after you drag your player tokens onto the map, you will need to slightly move EVERY LIGHT SOURCE. This is a huge hassle if you're using a map with lots of light sources. The fastest way that I have found to do this is to highlight a light-emitting token, use Ctrl-C to copy it, delete the token, and then use Ctrl-V to paste the same token back in the same spot. Once you have reset ALL LIGHTS in this fashion, move the players to your map. Second Bug: Let's suppose that I create three tokens, all with vision. I set Token A to have Light Multiplier 100%, and I set Token B to have Light Multiplier 200%. I also create a Token C, which has Light Multiplier 100%, and has Night Vision to 60 ft.; I set up Token C's Night Vision with a green tint. I am going to use these tokens to represent three different characters, belonging to three different players, Alan, Bertha, and Charlie. I often have my Player Characters navigate tight quarters with bad lighting, so if I set things up so that players can only see through their own tokens' eyes, there's a lot of confusion, it's hard to keep them engaged, etc. So to improve their experience, I decide to make it so that all three tokens are controlled by all three players, because this allows them to see what the other players can see, instead of being strictly constrained by their individual characters' lines of sight. But there also are use cases where the same player might be running two or more characters. Regardless, there are plenty of instances where there isn't a 1-to-1 equivalence, where one player controls one and only one token. So I place these tokens on a map, with a Bright 20/Dim 20 light source like the one discussed in my first bug. Expected behavior is for Token A and Token C to "see" the light source as Bright 20/Dim 20, and Token B to "see" it as Bright 40/Dim 40. Token C, additionally, will "see" things that are only dimly illuminated or that aren't illuminated at all, provided they are in range, and when that happens, a green tint makes it obvious that this has happened. Because all three tokens are controlled by all three players, Roll20 shows the map in a fashion such that if a monster is within the range of Night Vision for Token C and Night Vision would matter, all three players see it that way. Which is good and expected. And if Night Vision doesn't work because Token C doesn't have line of sight to a particular monster, then it fails over to Token B's vision settings, where it might still be visible if something is dimly illuminated to Token B's vision. Again, good and expected. But there is no failover for Token A's vision constraints to show up. Token A and Token C always "see" as if they share Token B's Light Multiplier, even if a player uses Ctrl-L to constrain his or her vision to use Token A only. In essence, Ctrl-L only checks for line of sight when players use it; it does not constrain for illumination. This is an issue if, for example, we want to see whether Token A would actually be able to see a monster, and whether that monster is (from Token A's perspective) in Bright Light, Dim Light, or no light. From the GM's perspective all tokens appear to "see" as if they have Light Multiplier 100%, regardless of whether this is true; Token B looks as if it has the same vision settings as Token A, even using Ctrl-L. This is not as expected, and it's not desirable. If the GM uses Ctrl-L to check visibility through Token A or B, Token C's Night Vision tint disappears. This is actually great, and as expected. Ideally, I think that Ctrl-L (for players and GMs) would cause Light Multiplier and Night Vision to be constrained to use the selected token's settings. This is the mode of operation that I think is intuitive and expected for most users, and it probably also has by far the most utility in gameplay. The way it works right now isn't quite a bug, but it's not totally helpful.

Jelisa said: Hi everyone!&nbsp; While we work towards providing full support for Updated Dynamic Lighting, it was crucial that we updated our “pre-2021” Marketplace items to utilize the Updated Dynamic Lighting features. As items continue to undergo this conversion process, we wanted to make it clear that you still have the option to use LDL if you like. Last I heard, the maps and tokens need to both be in the same dynamic lighting mode, right? So, if I'm understanding this correctly, it sounds like the patch updates the maps, but not the tokens? (If so, the patch notes make it sound like everything &nbsp; would be converted.) Anyway, if that is the case, the maps would be in UDL mode and the tokens would all still be in LDL mode, breaking the dynamic lighting. In other words, the players wouldn't be able to see after the patch. And any NPC that you wanted to give sight would also need to be converted. Or, if the patch does switch over both the maps and tokens to UDL, and you switch back just the maps to LDL (the easier task), that will also break the dynamic lighting. Once again, the players wouldn't be able to see, and the fix would be massive as none of the tokens in the game would be able to see. I'm all ears if I'm misunderstanding how combining LDL/UDL works, or how the patch actually works, but at first blush this update doesn't change the fact that the patch is going to cause issues.

Jelisa said: it was crucial that we updated our “pre-2021” Marketplace items to utilize the Updated Dynamic Lighting features. As items continue to undergo this conversion process, we wanted to make it clear that you still have the option to use LDL if you like. As so often, roll20 has missed the main point. Why force UDL on? I totally understand that the content needed to be patched to be "UDL-ready". Fine. But, I repeat myself, why did you automatically turn it on ?&nbsp; Thanks, I guess that I can turn it off manually again, if I don´t want it. But why force it upon me in the first place? Those who already want to switch could turn UDL on as easily, you know...

When Explorer mode and Dynamic Lighting is active, tokens on the Token Layer appear slightly transparent to the GM. The amount of translucence seems linked to the "GM Darkness Opacity" Slider. How to replicate : - Activate Dynamic Lighting and Explorer mode on a Page - Drop or Draw something on the background layer - Drop a token on the token layer - When the token, hover the drawing or the background and you will be able to see through lightly. - Adjusting the "GM Darkness Opacity" slider will increase or reduce this effect, when at 100% the tokens do not appear transparent. If the token has vision and the GM has been expressly declared as controlling the token (by putting the GM's name in the "Controlled by" field of the token), the particular token will not appear transparent regardless of the "GM Darkness Opacity" level. Tokens in sight from the token will still appear transparent. When seeing through a token's sight (CTRL-L), no tokens appear transparent, regardless of the "Controlled by" field or the "GM Darkness Opacity" level. The combination of these two particular effects make it so no player see this transparency. Here is a link to the few tests I've made (the black lines and text have been added in paint) :&nbsp;<a href="https://i.imgur.com/aZljkMi.png" rel="nofollow">https://i.imgur.com/aZljkMi.png</a>

What will happen to existing maps using LDL when May 18th arrives? Will those maps suddenly become broken and unusable? Or will the maps currently using LDL automatically switch to UDL?

Irondrake said: What will happen to existing maps using LDL when May 18th arrives? Will those maps suddenly become broken and unusable? Or will the maps currently using LDL automatically switch to UDL? At the very least when they remove LDL, then the maps will just not have any lighting enabled on them at all.

Irondrake said: What will happen to existing maps using LDL when May 18th arrives? Will those maps suddenly become broken and unusable? Or will the maps currently using LDL automatically switch to UDL? That's a pretty good question that I don't think has been asked. My guess would be that the maps will not have any LDL settings, and you can use the conversion script linked on the campaign home page to convert to UDL. I do not think there will be any automatic conversion. I would also guess that the message on the campaign home page will change with more direct wording about the need to convert. But an official statement will doubtless be forthcoming as the date approaches.

keithcurtis said: My guess would be that the maps will not have any LDL settings, and you can use the conversion script linked on the campaign home page to convert to UDL. I do not think there will be any automatic conversion. But without the old LDL settings being available any more, the tool won't know how to convert all the settings over to UDL.

I'm guessing the values will remain, but just be inaccessible. The amount of data they consume is miniscule.

If they stick to their May 18 date, it would be cool if they only implemented the change for new maps, leaving the LDL options enabled for existing maps. The old maps would die out through attrition. Of course there would be some that would just update their old map layers with new images. Maybe no support at all for those users (use at your risk).

If they stick to the May 18th date with the current state of things they are going to lose me as a customer; it's ridiculous that they announced that date and a "UDL 1.0" in the first place, now it's getting even worse with them forcing it on through modules updates; like someone else said they could have updated the modules and left the settings for LDL. I've asked this already and never got a reply, can we please have an official comment on if the sunset date will actually be respected?

Just had my first full-game experience with the latest version of UDL. Worked fine for me in Chrome on a high-powered Ubuntu workstation laptop, but my wife with a mid-powered Windows gaming laptop was really struggling. She kept seeing UDL bugs--mostly light coming through walls in places it shouldn't and shadows showing up where there should have been no shadows, even as it worked fine for me. Making it harder to debug was that the Control+L shortcut let the GM see through the eyes of our tokens mostly correctly , but the shortcut was reporting weird problems that we weren't actually seeing as players--the GM could see through walls while seeing through our tokens, while we properly saw walls as opaque.

I want it over and done with, and the canvas back end to be history.&nbsp; I want the webgl version functional so that some of the suggestions dealing with dynamic lighting can be in the pipeline that have been waiting for this transition.&nbsp; I want the possibility of adjustable dynamic light, colored lighting, etc.&nbsp; Bring it on.&nbsp; Delay if needed, but bring it on.

So, I sit, and I watch, and I listen.&nbsp; We are on a forum where the supplier (Roll 20) has asked it's users to please use an in development product and provide them feedback of bugs and issues so they can be addressed.&nbsp; The supplier is looking for information from the customers.&nbsp; This is a good thing. A very good thing actually.&nbsp; And while communication has been poor, it has been improving and it is obvious that they are actively working the issues the users have raised to get resolution.&nbsp; However, this forum has become more of a bitch session as to why the system shouldn't be changed.&nbsp; The complaining has been happening about change for months.&nbsp; As a matter of fact, as soon as the sunset date was announced it started, almost immediately.&nbsp;&nbsp; As counterweight, as a paying customer, I want the change.&nbsp; The change in dynamic lighting allows other changes I want.&nbsp; The change process is going to be difficult.&nbsp; A number of my scripts and other features are going to be broken for a while.&nbsp; Changing to UDL is going to cause me much pain.&nbsp; Please continue.&nbsp; Please launch a 1.0 version of dynamic lighting that provides the same function as current.&nbsp; And then please continue to enhance it and provide more features.&nbsp; Please sunset LDL.&nbsp; As a paying customer that's what I've asked for and that's what I want.&nbsp; That's also what my players want, so I speak for all 10 of us. I am confident that if the change is not ready come close to the sunset date that it will be delayed.&nbsp; I am also confident that Roll20 isn't going to say anything about delays until close to sunset date (like a few days before).&nbsp; They are currently in a damned if do / damned if don't situation.&nbsp; If it's not ready and they delay, a significant percentage of the user community is going to go "see, here we go again, you said improvements and you are delaying yet again".&nbsp; But if they don't delay and it's not considered ready by some users we get "see, here we go again, you released another POS on the user community, why didn't you delay". Why would anybody set themselves up for that before they have to?&nbsp; Announcing a delay or not a delay is only going to generate negative comments from some dissatisfied group.&nbsp; Roll20 will evaluate status a few days before, and make an announcement then.&nbsp; I'm not sure why anybody is expecting anything different. Have some faith and some patience.&nbsp; It is obvious the developers are working hard to make this improvement work.&nbsp; When they first announced it was available to try it was awful.&nbsp; It's been getting better.&nbsp; There are some features that are broken or not working well that I am avoiding.&nbsp; But by and large UDL is better today than it's ever been.&nbsp;&nbsp; My advice.&nbsp; Use it, try it, provide feedback.&nbsp; Constructive, helpful, feedback with documentation, screen shots, and an explanation of the systems behavior and what you think it should be.&nbsp; That's the only way to make it better and get a product that is useful to the users.&nbsp; Just make sure you take steps to protect yourself.&nbsp; When I want to try a map in UDL, I make it in LDL first, then make a duplicate, and then change the settings (map and characters), so I basically have an LDL backup copy, just it case there are problems.&nbsp; It may be a pain, but I can always switch over.&nbsp; I choose the maps I make in UDL with caution.&nbsp; I make sure that hidden villains are on the GM layer not hidden behind walls.&nbsp; It's a pain, but just in case I have to flicker the map to LDL and back they may know the layout, but at least they can't see the creature behind the wall. Finally, if it's that important to you that UDL be delayed and you feel like threatening Roll 20 with your subscription, perhaps you should just go ahead and leave.&nbsp; If the thought of change and the risk to your games is that distressing to you, why wouldn't you reduce your stress level and go somewhere else?&nbsp; Watching the conversation it seems like a number of commenters are in a bad relationship threatening their partner with "I'll leave if you don't change".&nbsp; I'm not aware I've ever seen that work.&nbsp; If you're that unhappy...&nbsp; And personally, I'm kind of tired of wading through the threats to see what bugs others are reporting.&nbsp; I am sure I speak for a number of people who are watching this forum that I want to see bug reports and responses from the developers.&nbsp; I'm not much interested in all the other stuff.

Michael D. said: We are on a forum where the supplier (Roll 20) has asked it's users to please use an in development product and provide them feedback of bugs and issues so they can be addressed.&nbsp; It has been claimed several times by roll20 that UDL is ready-for-use. Patches enable UDL automatically. The - working - LDL was announced to be disabled soon. Your rightfully point out that UDL is in the middle of development and needs severe testing. Which is now mainly performed by paying customers who thought that UDL was ready to use. You, a pro user like me, pay for testing a product. Nobody would complain had roll20 asked for beta-testing of an optional feature that would roll out only when it is ready. But this is simply not what happened or is still happening.

Vince M. said: Nobody would complain had roll20 asked for beta-testing of an optional feature that would roll out only when it is ready. But this is simply not what happened or is still happening. This is a very important point.&nbsp; If they kept it on the Dev server and listened to feedback and waited until it was ready, then when they swapped, one or 2 bugs wouldnt have been an issue.&nbsp; They said that they didnt have enough people on the Dev server to test it enough.&nbsp; I think this is one of the bigger problems, why lock the Dev server out to pro users only?&nbsp; Open it up to any one who wants to play around and give feedback.&nbsp; They could have had way more people giving feedback rather then people having their games ruined and complaining about paying to do Roll20's quality control.

At this point, Roll20 is going to do what they do, providing the minimal amount of "lip service" to their customers, not correcting existing bugs as we speed towards the LDL sunset date, apparently spending their resources developing new features. And those new features have bugs that would have been immediately seen had they done any real internal QA.

Vince M. said: Michael D. said: We are on a forum where the supplier (Roll 20) has asked it's users to please use an in development product and provide them feedback of bugs and issues so they can be addressed.&nbsp; It has been claimed several times by roll20 that UDL is ready-for-use. Patches enable UDL automatically. The - working - LDL was announced to be disabled soon. Your rightfully point out that UDL is in the middle of development and needs severe testing. Which is now mainly performed by paying customers who thought that UDL was ready to use. You, a pro user like me, pay for testing a product. Nobody would complain had roll20 asked for beta-testing of an optional feature that would roll out only when it is ready. But this is simply not what happened or is still happening. this. I joined roll20 and spent additional money buying books because of the feature set they had on offer, if they remove one the main features that led me to spend that money replacing it with something that is not usable i feel i have all the right to at least give them the feedback that this is not the way to treat paying customers. That said, obviosuly the roll20 staff is not interested in partecipating in any of these feedbacks/comments/discussions, at this point even if they end up fixing the UDL mess I am not interested in giving any more money to a platform that doesn't care about its users so i went ahead and disabled my subscription (got another month or so paid for and then i am moving to foundry), the only reason i am mentioning this is the hope they will take it as a feedback for future. good luck to you all

Thanks for the detailed update, Corey!

Thank you for the update!&nbsp; Will definitely pay attention tonight and see if any of these issue reappear.&nbsp; Keep of the good work, keep charging!