UDL 1.0 Updates, Bugs, & Feedback

Thanks, Katie Mae! On the light multiplier issue, it seems a lot of people are getting tripped up by the same assumption I made: that light multipliers will apply to vision. In LDL, vision is simulated by a light emitting from a token that only the token can see. This "just for me" light can be multiplied. In UL, vision seems to work more like, well, vision. The token can see to a distance, but since it's no longer emitting light, the multiplier has no effect. Here's the issue... I'm not really sure there's a ton of value (or any value?) to having a multiplier on static light emitting sources. If I want a lantern to cast bright to 20 and dim for another 20, well.... I'll just do that. The entire point of the multiplier (I think) is to enhance  vision . A character with 60' darkvision in 5e can see bright light as bright light, dim light as bright light, and darkness as dim light to 60'. In LDL, I follow this method from the R20 wiki... Darkvision  Characters with darkvision are able to see in dim light as if it were bright light and in darkness as if it were dim light, usually out to a radius of 60ft. To represent this we'll create a "light source" for that token, that only that token can see. What separates it from acting like a  Lantern  is that the  All Players See Light  box is not checked. Also, to brighten the dim light of other light sources to bright light for this character, we set a multiplier of 2, but we set a light radius of only 30. In the absence of light, the area the character can see as dim light will be doubled by the multiplier, achieving the required radius of 60. For example, darkvision of 60ft would look like: Light Radius  = "30" Start of Dim  = "0" All Players See Light  = "Unchecked" Has Sight  = "Checked" Multiplier = "2" So...... if the light multiplier isn't working on UL vision  but only on UL sources , then it's kinda not working much at all. Hope that helps the devs.

I'm seeing proper results. I just grabbed a map, so the token choices are silly. All shots are taken from a  Dummy Account , with the DA controlling the rifing horse. The dead wolf emits 10ft of dim light and 10ft of bright. The Riding Horse has vision with a light multiplier of 100% Here is the same shot with the horse having a light multiplier of 200%

Yep, I got the light multiplier to work but only when I moved the light emitting token. In other words, changing the observer token's LM from 100% to 200% didn't appear to do anything until I moved the LET. The confusion, at least for me, stems from what it says in the Light Multiplier description. It literally says, "...This changes the effective radius of light for this player." which alludes to the light emitted by the token setting, and, "...will let this player see light..." which alludes to the VISION of the token being affected. Clarification on how it works and usage case would help greatly . I've never used it.

"effective" would be the keyword here. It is not changing a light value, but only the effect of it as seen by the player. I.e. the vision of the token sees the effect of emitted lights at 200%. The lights don't change, only their effect on the viewing token. Also, I saw immediate changes without needing to move anything. Were you testing with a Dummy account or Ctrl-L?

Keith, the way I'm checking it currently, I'm just looking at the character's darkvision view (via Ctrl-L). With UL enabled, 30 feet of darkvision and a 2x multiplier, the character can only see 30 feet, when they ought to be able to see 60 feet. So while they might be getting doubled view of external light sources, it doesn't seem like they're getting doubled view in the dark. ETA: if Ctrl-L doesn't show the PC's view distance accurately, that's a whole other issue, as the GM frequently needs to know what the PC can or cannot see.

Ctrl-L is very limited to begin with, and really can lead to confusing results if it is relied on to test DL solutions. It was originally built just to test L ine of sight for the GM, but because of this a persistent myth has grown about it that it shows an accurate view of the token's vision. This has never been true. Unfortunately, even given this, Ctrl-L on UDL is flawed. Don't use it as a guide or trust it. Use a  Dummy Account . This advice was true even under LDL.

Copy that. I'll give it a go.

I used a dummy account, and I can confirm that the light multiplier does not  increase the token's distance of night vision. Hopefully they fix that, as I don't see why it shouldn't. 

Why should the light multiplier multiply night vision distance? Why not just increase night vision distance? It does what it says it does, multiplies the distance of light sources for the character with the multiplier. For other characters, the light appears normal.

Huh. I suppose you're right. I'm so used to the other paradigm... maybe I got into a little brain rut there. Thanks! Objection withdrawn.

It makes more sense this way, but it's definitely going to take getting used to. 

keithcurtis said: It should not happen with your players. The revealed area is player based, not character based. Ctrl L won't test for that. Use a  Dummy Account  instead. To check your specific concern, you might need two dummy accounts. Many thanks Keith, that helps. Nevertheless, I'd still appreciate if the Ctrl+L give the GM the player/character vision. It is strange that before I move the tokens, one didn't see another's surround, only after. On LDL that worked just fine.

keithcurtis said: Why should the light multiplier multiply night vision distance? Why not just increase night vision distance? It does what it says it does, multiplies the distance of light sources for the character with the multiplier. For other characters, the light appears normal. Yes, I think that since the light multiplier is on the token (not global), then simply doubling night vision distance is all that is required if the game system wants vision to work that way.

Katie Mae, when you get the chance, could you update the top post? It's nearly a month old, and doesn't show the latest fixes, or the current status of reported bugs. It does not even list the Sunset date. Thanks!

Doug E.'s description of March 14 (here:&nbsp;<a href="https://app.roll20.net/forum/permalink/9900485/" rel="nofollow">https://app.roll20.net/forum/permalink/9900485/</a>) is accurate to the behavior that I currently experience, using a dummy account. For the sake of making my use case and expectations as clear as I can: 1) I am using UL to emulate the vision mechanics used in D&amp;D 3.X/Pathfinder 1E. In those systems, a light source has an expressed light radius, in which it sheds bright light. In most cases, a "shadowy" area equal to this radius is also present around the radius. In the example of a torch, this is a 20-ft. radius of bright light, surrounded by an additional 20 ft. radius of shadowy light, for a total 40 ft. radius. It is effectively a "bull's eye" configuration with a total diameter of 80 ft. UL has no trouble configuring a light source that covers these parameters. I can set the toggles under Token Emits Light to on for both bright and low light, with both at 20 ft., and I have torchlight. Easy-peasy. 2) If a character token is configured to have normal vision--no night vision, light modifier 100%--then the light source described in 1) appears as expected. This accurately models 3.5/PF 1 vision mechanics for humans, as well as many other creature types. 3) If a character token is configured to have normal vision plus 60 ft. night vision, the light source appears as expected, which means that if the token is more than 60 feet from the edge of the light source's shadowy illumination, it can see the illuminated areas the same way as in 2), and it also sees a 60 ft. radius via its night vision. This accurately models 3.5/PF vision mechanics for a dwarf, half-orc, or similar creature that has normal vision plus what those systems call "darkvision." 4) If a token is configured with Light Modifier 200%, it sees bright illumination in a 40 ft. radius around the light source from 1), and no low illumination at all . If I move the light source, then the token's vision changes to show a bright radius of 40 ft., and low illumination radius of 40 ft., which is the expected behavior. If it is performing as expected, this configuration emulates the 3.5/PF mechanic for "low-light vision" which should allow a creature such as an elf to see twice as far as a human under conditions of shadowy illumination. 5) If a token is configured with Light Modifier 200% and night vision 60 ft., the night vision seems to be completely unaffected by the light modifier. This is as expected. The buggy behavior described in 4) is still evident, however. Based on this odd behavior, I assume that case #4 is a bug. To duplicate it, you must set up a light token as described, place it on the map, and then create a token using Light Modifier 200%. The buggy behavior is evident regardless of whether you set up a new token or use a preconfigured one that you drag from the Journal for a character. Screenshots follow; I have used a blue tint with night vision for these, in order to make it easy to see the difference. Please note that in all cases, the bugged behavior seems to require me to move the light-emitting token to end it for that token and get the light sources to behave as expected. That is, it's not a workaround where I can fix one and it fixes all of them. Above, the GREEN token is configured with normal vision. Light sources at the north and south are behaving as expected. The green token is configured with night vision, tinted blue to make it easy to differentiate. This functions as expected. The green token is configured with Light Modifier 200%. It is bugged; the radius on the northern light source is set to 20 ft. bright and 20 ft. low, as described above, but it is visible as 40 ft. bright with no low. Green has the same settings as before, because it is the same token. I moved the northern light source slightly and then moved it back, and the bugged behavior gave way to expected 40 ft. bright, followed by 40 ft. low illumination. The southern light sources are still bugged, because I didn't touch them. This behavior is not intermittent for me; it happens without fail, anytime I use Light Modifiers. And if I refresh the page for Roll20, the bugged behavior immediately returns, even after I have fixed it by moving light sources. In addition to this, if I set up two tokens, one with a 200% Light Modifier, and one with only 100%, and I set them both to be "Edited and Controlled By" by the same player (or all players), both tokens see as if they had a 200% light modifier. This is not as expected. Given that I am a customer (that is, I pay actual money TO YOU), I should not be doing your QA work for you. I don't wish to be unpleasant or dwell excessively on it, but it is not at all acceptable that your users are doing a difficult, time-consuming task for you, without compensation, and Roll20's conduct by bringing LDL to sunset while UDL is as half-baked and buggy as it is has me contemplating other solutions for my game. I've sunk a lot of time into this platform getting maps set up with dynamic lighting, or I would already be gone. The fact that a customer is having to walk you by the hand through bugs that are so obvious and so easy to reproduce is pretty unacceptable.

Edward R. said: Given that I am a customer (that is, I pay actual money TO YOU), I should not be doing your QA work for you. I don't wish to be unpleasant or dwell excessively on it, but it is not at all acceptable that your users are doing a difficult, time-consuming task for you, without compensation, and Roll20's conduct by bringing LDL to sunset while UDL is as half-baked and buggy as it is has me contemplating other solutions for my game. I've sunk a lot of time into this platform getting maps set up with dynamic lighting, or I would already be gone. The fact that a customer is having to walk you by the hand through bugs that are so obvious and so easy to reproduce is pretty unacceptable. Hope you're listening, Roll20...

Jay R. said: Edward R. said: Given that I am a customer (that is, I pay actual money TO YOU), I should not be doing your QA work for you. I don't wish to be unpleasant or dwell excessively on it, but it is not at all acceptable that your users are doing a difficult, time-consuming task for you, without compensation, and Roll20's conduct by bringing LDL to sunset while UDL is as half-baked and buggy as it is has me contemplating other solutions for my game. I've sunk a lot of time into this platform getting maps set up with dynamic lighting, or I would already be gone. The fact that a customer is having to walk you by the hand through bugs that are so obvious and so easy to reproduce is pretty unacceptable. Hope you're listening, Roll20... +1. One thing is if i notice a bug in a proven system and report it with some steps, another if you need people to do the amount of reporting that has been happening in this thread. I have no interest in working as free QA, especially considering the fact that i am the one paying you For what is worth, I have been actively looking for alternatives after seeing the way you have been handling the UDL upgrade

Angelo said: Jay R. said: Edward R. said: Given that I am a customer (that is, I pay actual money TO YOU), I should not be doing your QA work for you. I don't wish to be unpleasant or dwell excessively on it, but it is not at all acceptable that your users are doing a difficult, time-consuming task for you, without compensation, and Roll20's conduct by bringing LDL to sunset while UDL is as half-baked and buggy as it is has me contemplating other solutions for my game. I've sunk a lot of time into this platform getting maps set up with dynamic lighting, or I would already be gone. The fact that a customer is having to walk you by the hand through bugs that are so obvious and so easy to reproduce is pretty unacceptable. Hope you're listening, Roll20... +1. One thing is if i notice a bug in a proven system and report it with some steps, another if you need people to do the amount of reporting that has been happening in this thread. I have no interest in working as free QA, especially considering the fact that i am the one paying you For what is worth, I have been actively looking for alternatives after seeing the way you have been handling the UDL upgrade +1 and I would like to add that Angelo was nice and only mentioned the amount of reporting in this thread, neglecting the previous thread and the thread before that thread. I personally wouldn't be as agitated if I hadn't seen the allocation of funds of roll20 into youtube advertisements instead of funneling it into R&amp;D (or hiring The Aaron or keithcurtis)

Falk said: Angelo said: Jay R. said: Edward R. said: Given that I am a customer (that is, I pay actual money TO YOU), I should not be doing your QA work for you. I don't wish to be unpleasant or dwell excessively on it, but it is not at all acceptable that your users are doing a difficult, time-consuming task for you, without compensation, and Roll20's conduct by bringing LDL to sunset while UDL is as half-baked and buggy as it is has me contemplating other solutions for my game. I've sunk a lot of time into this platform getting maps set up with dynamic lighting, or I would already be gone. The fact that a customer is having to walk you by the hand through bugs that are so obvious and so easy to reproduce is pretty unacceptable. Hope you're listening, Roll20... +1. One thing is if i notice a bug in a proven system and report it with some steps, another if you need people to do the amount of reporting that has been happening in this thread. I have no interest in working as free QA, especially considering the fact that i am the one paying you For what is worth, I have been actively looking for alternatives after seeing the way you have been handling the UDL upgrade +1 and I would like to add that Angelo was nice and only mentioned the amount of reporting in this thread, neglecting the previous thread and the thread before that thread. I personally wouldn't be as agitated if I hadn't seen the allocation of funds of roll20 into youtube advertisements instead of funneling it into R&amp;D (or hiring The Aaron or keithcurtis) +1

Anyone wanna take bets on when moderators close this thread down, start a new one and specifically call out in the first post that comments regarding customers doing free QA are "not appropriate"?

João Luiz said: Falk said: Angelo said: Jay R. said: Edward R. said: Given that I am a customer (that is, I pay actual money TO YOU), I should not be doing your QA work for you. I don't wish to be unpleasant or dwell excessively on it, but it is not at all acceptable that your users are doing a difficult, time-consuming task for you, without compensation, and Roll20's conduct by bringing LDL to sunset while UDL is as half-baked and buggy as it is has me contemplating other solutions for my game. I've sunk a lot of time into this platform getting maps set up with dynamic lighting, or I would already be gone. The fact that a customer is having to walk you by the hand through bugs that are so obvious and so easy to reproduce is pretty unacceptable. Hope you're listening, Roll20... +1. One thing is if i notice a bug in a proven system and report it with some steps, another if you need people to do the amount of reporting that has been happening in this thread. I have no interest in working as free QA, especially considering the fact that i am the one paying you For what is worth, I have been actively looking for alternatives after seeing the way you have been handling the UDL upgrade +1 and I would like to add that Angelo was nice and only mentioned the amount of reporting in this thread, neglecting the previous thread and the thread before that thread. I personally wouldn't be as agitated if I hadn't seen the allocation of funds of roll20 into youtube advertisements instead of funneling it into R&amp;D (or hiring The Aaron or keithcurtis) +1 +1 Also lets not forget the amount of bugs this free QA has found that haven't been fixed in months despite being large issues with the system that, as many people have been rightly pointing out, are deal breakers.

The other night I was chatting with my fellow DM after his game on Roll20. He's been playing in my games on Roll20 for the last 7 years, and has been running his own games for several years now which I play in. We're both Pro members. We both are busy professionals who buy our adventures from Roll20. I'm running Avernus and he's running Frost Maiden. Anyway, I asked him how his game went and he said at this point he spends his whole game stressing about whether everyone can hear each other over Roll20 audio, and can see the maps because he made the mistake of updating to the new lighting. Immersion is impossible. I told him there was a bit of feedback about that on the forums, but he doesn't read them. It's become increasingly clear to me that Roll20 has grown up, and not for the better. They've changed from a VTT that was also a marketplace, to a marketplace which also runs a VTT. You'll notice there's never any issues having the next product ready for pre-sale. You'll notice there's no holding back on announcements of how many millions of subscribers Roll20 has now. However, it's becoming increasingly unclear where the increased profit is going, because it's certainly not going back into improving the VTT. When long time, loyal, paying members communicate their frustration they're met with bizarre replies from the moderators. Some are completely tone deaf (yeah UDL sucks, so we're sunsetting the one that works!), others are a window into a dysfunctional company (we're actually sunsetting so our devs have a deadline they will follow!), and others are like a parent speaking to a child (gosh kids, we've added bug #2018 to our list. We haven't gotten through the original list from a year ago, but trust us, the ever growing list will be totally done in 3 months!). There's no reply or response at all how much free QA the paying members are doing merely in hopes that this broken feature will be fixed enough to run their games... which they're paying Roll20 to run... After a tough conversation my friend (and our combined 8 players), we have decided that we're going to take the sunsetting of the old dynamic lighting system as our time to sunset from Roll20. This was a very hard decision as I'm sure many of you know. As DMs, all of our stuff is on Roll20. It's going to be painful to move, and painful to learn a new VTT, but the pain we're feeling on Roll20 now exceeds the pain it will take to move. Fortunately there's now some really decent competition at Foundry and Fantasy Grounds.

After almost 4 years as a gamemaster on Roll20 I have now begun the process of moving to another VTT. It has become obvious that Roll20 as a company is far more focused on generating revenue from licensing deals and other alternative revenue producing streams, than from providing a high quality product. I believe this is evidenced by the amount of licensing content being released at a hectic rate, and sadly this is (in my opinion) causing Roll20 to fail to maintain the stability of their platform, not to mention the current problems associated with Dynamic Lighting. Regardless of the comments from moderators, it is obvious that customers pleas are being largely ignored. In addition, relying on paying customers to debug your product is an absolute disgrace, and having worked in the IT industry for 20 years I am absolutely boggled by the lack of comprehension that Roll20 appear to have regarding the damage this mindset is doing to the Roll20 brand. The fact that a rollout of UDL has been deadlined, regardless of it's lack of stability and outstanding bugs, is a clear indication that Roll20 have lost sight of the basic fundamentals of providing a VTT product to the marketplace. The only reason I am still here is because of the amount of work I still have to do to transition my games over to the new provider. Once this process is complete, I will never come back.

Once again, hope you're listening, Roll20...

I feel as if my comment of March 17 has reignited customer commentary that Roll20 probably would prefer not to have had rear its head. At the time, I said with all sincerity that I did not wish to be unpleasant or to dwell excessively on the matter. That is still how I feel. I do not want to take my business elsewhere; most users on Roll20 are playing D&amp;D 5E, which is a competitive market niche for VTTs because it's the most current edition of the most popular RPG in the world. I'm playing 3.5/PF1, which is older and not as well-supported on other platforms; the features that model 3.5/PF1-style low-light vision are buggy here, but nonexistent elsewhere, for example. I am not even particularly concerned with the lack of feature parity between UDL and LDL, because I am using UDL; bugs aside, I get much better performance with it, even if LDL is less buggy. If I'm running combat encounters on a large, heavily populated map, then LDL is kind of painful to use. Unfortunately, UDL is buggy enough that I cannot say it dependably functions as advertised. More than half the time, it doesn't. So either way, I'm kind of in an unsatisfactory position. If I cannot model the game mechanic I need with the tool I have, then it won't be too much longer before I start looking around for a better tool. So my gripes about UDL have little to do with the May 18, 2021 sunset date for LDL. That looks like it's probably a colossal blunder, just in terms of what it's going to do to customer satisfaction, and the effects that it is already having on the goodwill of Marketplace Creators. But&nbsp; . . . eh. Not my circus. Not my monkeys. I am here because I am paying for access to a tool that I use to pursue an enjoyable hobby, and I think it should be pretty uncontroversial when I say that if I am paying for the tool, I expect it to work as advertised. Roll20 currently is not delivering on this modest expectation, and needs to do better. That said, I shouldn't be on this forum, logging bug reports with user scenario, screenshots and repro for something that's happening in a production environment. Put aside the question of whether customers should be writing QA reports for a second; customers shouldn't be seeing these kinds of bugs, because adequate QA by Roll20 would ensure that they never make it off the Dev server. I am not going to be writing more bug reports; I have some past experience as a technical writer who sometimes had to pitch in to do a little QA, and I didn't much care for it even when I was being paid for the work. :P

Edward R. said: I am here because I am paying for access to a tool that I use to pursue an enjoyable hobby, and I think it should be pretty uncontroversial when I say that if I am paying for the tool, I expect it to work as advertised. Roll20 currently is not delivering on this modest expectation, and needs to do better. That said, I shouldn't be on this forum, logging bug reports with user scenario, screenshots and repro for something that's happening in a production environment. Put aside the question of whether customers should be writing QA reports for a second; customers shouldn't be seeing these kinds of bugs, because adequate QA by Roll20 would ensure that they never make it off the Dev server. I am not going to be writing more bug reports; I have some past experience as a technical writer who sometimes had to pitch in to do a little QA, and I didn't much care for it even when I was being paid for the work. :P Nailed it.&nbsp; (also speaking as someone who used to be a tech writer many moons ago and who also didn't enjoy doing QA even when he was getting paid for it...)

TheWebCoder said: It's become increasingly clear to me that Roll20 has grown up, and not for the better. They've changed from a VTT that was also a marketplace, to a marketplace which also runs a VTT. You'll notice there's never any issues having the next product ready for pre-sale. You'll notice there's no holding back on announcements of how many millions of subscribers Roll20 has now. However, it's becoming increasingly unclear where the increased profit is going, because it's certainly not going back into improving the VTT. When long time, loyal, paying members communicate their frustration they're met with bizarre replies from the moderators. Some are completely tone deaf (yeah UDL sucks, so we're sunsetting the one that works!), others are a window into a dysfunctional company (we're actually sunsetting so our devs have a deadline they will follow!), and others are like a parent speaking to a child (gosh kids, we've added bug #2018 to our list. We haven't gotten through the original list from a year ago, but trust us, the ever growing list will be totally done in 3 months!). There's no reply or response at all how much free QA the paying members are doing merely in hopes that this broken feature will be fixed enough to run their games... which they're paying Roll20 to run... This. Absolutely this. Roll20 has been brilliant in drawing people into the hobby and allowing distant friends to communicate. The fact that it offers free accounts, that allow everyone to play their games for no money, is brilliant. I love Roll20 for that. And always will. However, since paying for a subscription I have hit nothing but frustration. UDL is broken, that much is obvious. I had to stop a game early two weeks ago when 3 of my players couldn't see anything, and one of them could see the entire map. But bugs are ok - they are part of the world we live in. I come from a software business background, as do many on here, so I know the issues R20 face. But the attitude of R20 is NOT ok. Declaring the sunsetting of a feature that works to be replaced with a feature that obviously doesn't, and then COMPLETELY IGNORING their users when they point out why this is a bad idea, is not good for business. What is worse, for me at any rate, is that all the features that I would like to have - the ones raised as "suggestions" on the appropriate forum, the ones that have many hundreds of votes and comments - are not only completely ignored (no official R20 feedback or acknowledgement in the threads, or mention in the so-called "roadmap") but they have been on these forums, unimplemented and ignored for many YEARS. I have no confidence that anything I have voted for will be even acknowledged, let alone implemented. And any other suggestion that doesn't magically gain momentum in 30 days will get shut down.&nbsp; I feel that since I started paying for Roll20, and thus started to have expectations of it, I have continually struggled against it, rather than worked with it. Most of my macros, working practices, tweaks and scripts are work-arounds, where they should be utilising features that should be part of the VTT (and are already part of rivals). It is members of this community, NOT Roll20, that have kept me here for the last few months. People like KeithCurtis, who continuously does the job of a Roll20 member of staff - responding to queries, calming rants and offering advice - without being one, and theAaron, who provides free API scripts for people in need. And many others. But I've had enough. My "Pro" tag will disappear at the end of this month's cycle. I have already ported everything over to a rival VTT (I won't mention it, but I'm sure you can guess) and after only a week of getting up to speed with it, I have far, far surpassed "feature parity" with my Roll20 system. And I am paying less for it in the medium and long term. It's a shame - Roll20 still has great offerings and I wish it well. But if it continues to ignore its paying customers, and blindly quotes how many users it has (remember it's the paying customers who are leaving, not the users!), it will soon be overtaken in users - it already has been overtaken in features. Sorry to hijack this thread (which, after all is about UDL feedback!) but, as with many, I need to vent my frustrations somewhere. And Roll20 does not seem to be listening anywhere else. Roll20 Pro - So long, and thanks for all the Sahuagin.

Hey, dumb little fix, but as a visual note, you can apply&nbsp; object-fit:cover &nbsp;to the character icon &lt;img&gt; tags in the campaign details tab and other locations with the small icons, to have them size nicely to the circular frame. Without object-fit:&nbsp; &nbsp; &nbsp;With object-fit:&nbsp; Love the site!

The two topics are interlinked at this point, ¯\_(ツ)_/¯ It's hard to take roll20's promises about parity, let alone functionality , at face value given the history of UDL, its progress (or lack thereof), and how roll20 staff have been communicating with its users. As I myself and numerous others have previously pointed out. As a reminder the most recent bought of quote-unquote "off-topic" discussion came about because Edward R. was able to easily and quickly replicate an earlier reported bug. Which is apparently in fact not a bug, but a feature... that no one understood because again, roll20 is failing to communicate clearly with its user-base, the history of statements being made and not met, and the fact that r20 is currently in the midst of taking away a working product and replacing it with a broken one. I don't personally use UDL because it does not work . If I pay for a product I expect it do as advertised, and UDL does not. I follow this thread, much as I followed the one before it and the one even before that and etc., since the initial announcement about changes to lighting in November of 2018 , in order to keep abreast of UDL's progress. In all that time there's been nothing to convince me that roll20 has a suitable replacement for my group's needs, nor that they will any time soon. An arbitrary date tied to the release of a product for sale on the platform certainly creates a very narrow window for such expectations to be met and overcome, and miscommunications (the most charitable interpretation!) about various parts of UDL, or the goals that have been set forth to be presumably met before then, or the rationale given for such changes, don't help in the least.

Wint said: Edward R. was able to easily and quickly replicate an earlier reported bug. Which is apparently in fact not a bug, but a feature This is not accurate. I did not misunderstand how the feature works, and to my recollection nobody has suggested that this is not a bug, or that my account of it was actually the intended function. I would actually like to see this get fixed, so please don't muddy the waters by reinterpreting what I have said in this discussion. This is not a case of it being unclear to me what the feature was supposed to do. The Light Multiplier feature is heavily bugged. Doug E.'s earlier post about the same bug indicated some confusion about whether the Night Vision feature should be multiplied by Light Multiplier. In LDL, it is multiplied, because LDL does not observe a distinction between vision and lighting. In UDL, it is not multiplied, and I did not expect it to be. UDL's Night Vision and Light Multiplier functionalities appear to work together as intended and expected. Doug E. then went on to describe the same bugged behavior with Light Multiplier for which I was readily able to achieve repro, and which I documented in my report. The Light Multiplier feature in UDL is supposed to increase or decrease the radii of any light sources visible to a token. That is, if you set Token #1 to emit Bright Light with a radius of 20 ft. and Dim Light with a radius of 20 ft., and you set Token #2 with vision and set its Light Multiplier to 200%, the expected behavior is that Token #2 will see the light source from Token #1, but it will see a 40 ft. radius Bright Light, and a 40 ft. radius Dim Light around that. It functions reliably and as intended for Bright Light sources. It does not function reliably for Dim Light. When it functions at all for Dim Light, it functions as intended. But it is not reliable, and its default mode of behavior is not to function. There is a workaround that I can perform to cause it to begin its intended function. So it is a bug. QED. Separately from this bug, I also have described another Light Multiplier bug. If Token #1 and Token #2 are set to have vision, and Token #2 is set to use Light Multiplier 200%, and if Token #1 and Token #2 are subsequently set to be edited and controlled either by a single player in common, or by all players in the game, both tokens see as if they have been set to use Light Multiplier 200%.

Katie's response from March 16th was that roll20 had found another bug, but regarding your specific issue that "The additional confusion about the light multiplier has also [ed: emphasis mine] been an indicator for us that we need to step up our current Help Center documentation about this feature, so that’s something we’re tackling as well." This indicates that roll20 doesn't consider it a 'bug' as you outline your definition above, but merely a feature they are not correctly documenting. I am not "muddying the waters" or "reinterpretating" your posts, I'm taking a literal read of statements made in this thread. Which all swings back to my previous point about roll20's failure to communicate clearly with its users. If any of this is incorrect I would love to see a correction from a member of roll20 staff.

Katie, I think one of the other reasons people post a few general comments about lack of communication, is that in all the suggestions lists, it has been months or years since a roll20 member has commented on progress, or what is included or not.&nbsp; So how else are we supposed to ask questions and get feed back on progress?&nbsp; A common response is "yes we need to work on our feedback and we are addressing it" this has been said a number of times by the staff, but you are about the only one responding and only on this thread. I would have thought at this stage with the UDL and again poor implementation of quality control checking of the recent character sheet "upgrade" roll20 staff should be commenting here on a DAILY basis, and to gain some good will back, an honest response on the top 10 suggested features would be a good step forward....but it would have to be honest and forthcoming, because at the moment I doubt many people trust the responses.&nbsp;&nbsp; As previously mentioned the only person trying to help is Keith and he doesnt work for Roll20. Perhaps a comment along the lines of "Thanks for everyone who has contributed to sorting out Roll20's bugs, here is a free year subscription of PRO as gratitude...." As you can see I no longer have a PLUS/PRO tag against my name, as I moved elsewhere.&nbsp; I follow along here because I get asked alot from friends what I would recommend and what are the features of various VTTs and I want to give them an honest answer, so when you fix the UDL I can say that roll20 has lighting, at them moment I cant say that and point them elsewhere. I have said in the past, I want roll20 to succeed, as competition is good for us consumers, we get a better product whether it is here or elsewhere.&nbsp; If roll20 surpasses the competition, then I may come back. I put my money and support behind the company that provides the best product, and one that I can trust.&nbsp; Its not just Foundry that is ahead here.&nbsp; Astral is improving daily and Owlbear Rodeo is another great free platform, and of course there are many other smaller ones coming along, and FG as well.&nbsp; I dont see on the forums of people leaving those ones to come to Roll20, I only see people leaving roll20 to choose one of those.&nbsp; Its not just 1 or 2, either, its dozens per day, and they are the ones that comment, so there must be many others.

Ran a session and lighting was down right unusable for my players I had to turn it off even after using the conversion tool as we ran into similar issues previously I’ve tried all the combinations one that had night vision set and one which emitted lighting one that had purely vision turned on. Very disappointed after a lot of lead up to a certain map and couldn’t get fog working either so resorted to drawing large colour squares to block...

Guys, I have a problem. In any game I have endless loading screen. I tried remove all extensions, join from other browser, join from new account and join from other device. Didn't work. My friends (3/4) has the similar problem. How can I solve it?

Same issue as Альфарий has, me and my friends cannot join any game from any browser. We tested many configurations and looks like VPN helps, but it works before today fine without it.

I'm not entirely sure what the point of posting in this thread is at the moment.&nbsp; You (Roll20 generally) collected a list of bugs and their status almost two months ago.&nbsp; We reported a bunch more.&nbsp; You then haven't seemingly fixed any of those except for giving us a dim light slider - and circles which weren't on the list and would break the games where I'm using circles as windows when you suddenly push it out without warning if I didn't know to prepare from reading this thread. There may have been a bunch of work to make things less laggy, or to make certain hardware work better, or back end changes that enable future bug fixes.&nbsp; Which would be nice, but it's not necessarily something we're seeing and hasn't been well communicated, so there is a bit of frustration about the seeming lack of progress.&nbsp;&nbsp; We would like to help.&nbsp; We'd love to get a working lighting system.&nbsp; But it's hard to identify and report any additional bugs, because it hasn't been made clear which of the existing ones on the giant list are things that are well characterized and just haven't been gotten around to yet, vs things you don't understand.&nbsp; And the existing bugs are so wide ranging, prevalent, and easy to reproduce that it isn't entirely clear whether we need to report more nuanced versions or if they'll just get fixed as part of the larger fix.

I saw another post this back in January, I am seeing the exact same issue.&nbsp; I'm having a problem with the dynamic lighting. In multiple games (all modules), my players will move their tokens and simply go blind. Like the dynamic lighting just turns off and they can't see anything. The only fix I've found is the turn off the dynamic lighting (revealing the whole map) and turn it back on, and even then they usually go blind the next time they move their token. So this is still an issue as of right now. I am working with a friend and trying to see what is happening. Using zoom to look at his computer and mine at the same time. Everything looks right on my computer, his is not working, the tokens lost all sight. If I turn off UDL save it, then turn it on everything comes back. Move a token and it is okay, then a minute later move a token and everyone goes blind again.&nbsp;

Bob DM S. said: I saw another post this back in January, I am seeing the exact same issue.&nbsp; I'm having a problem with the dynamic lighting. In multiple games (all modules), my players will move their tokens and simply go blind. Like the dynamic lighting just turns off and they can't see anything. The only fix I've found is the turn off the dynamic lighting (revealing the whole map) and turn it back on, and even then they usually go blind the next time they move their token. So this is still an issue as of right now. I am working with a friend and trying to see what is happening. Using zoom to look at his computer and mine at the same time. Everything looks right on my computer, his is not working, the tokens lost all sight. If I turn off UDL save it, then turn it on everything comes back. Move a token and it is okay, then a minute later move a token and everyone goes blind again.&nbsp; More information, we are both using Chrome and are on the same version of Chrome.&nbsp; YOU CANNOT TURN OFF LEGACY LUGHTING UNTIL THIS IS FIXED! THIS IS A SHOW STOPER.

This is a large part of the reason I unsubbed from roll20 and moved to a different VTT.&nbsp; It's been well over a year since UDL was released, a year or two longer than that since it was announced, and it still doesn't work well and/or properly for a large number of users and it's being sold as "ready for live."&nbsp; I have an Alienware with 32 GB of RAM and a 1.5 GB GPU and UDL still brings it to its knees if more than one player moves a token on a UDL-enabled map.&nbsp; I feel bad for the folks at roll20 who know better and are trying to make things better, but this process of it taking years to get relatively small improvements that come with a mountain of bugs and being told it's good to go is not something people want to pay subscription fees to receive.

Another bug to add to the first post. Reposted from: <a href="https://app.roll20.net/forum/permalink/9916969/" rel="nofollow">https://app.roll20.net/forum/permalink/9916969/</a> I noticed that if Dynamic Lighting is enabled, you're unable to rotate text placed in on any layer, but as soon as you disable it for the page you're able to do so. Was wondering is this is a bug, or some weird side affect that Dynamic lighting has on text.

Hey all, Just a couple of notes and a quick update. There have been some very good points raised here and I appreciate both your candor and that you took the time to share your thoughts (and the multitude of bug reports) here. First -- Альфарий and Kirill U. I hope you were able to get into your games. There had been a Cloudflare issue in a specific region. In the future please post in a new thread as they're unrelated to Dynamic Lighting. If you're still having problems, you can let us know in this thread . Second -- back to the UDL reports, please don't speak for other users. If you're trying to understand or emphasize someone's point by restating what you've read (or even quoting it) and they tell you you've misunderstood, respect that. Now if they agree with you, great! Rewording a concern or problem can sometimes bring new things to light. Third -- And about the very good points raised and the ask for clarity around what the status is of the known bugs and the current work, the team on this project will update on the statuses of the What Needs Worked On section from the first post (as well making sure it's up to date itself) by Friday, March 26. In the meantime, if there is any new feedback, feel free to drop it here! (Thank you for the report, Rabulias! )

For some of the reasons described herein, I don't have time to read through all of this except to say that I am experiencing several problems with UDL.&nbsp; One of them that is most concerning to me is that when I change lighting on one page, it seems to have effects on other pages.&nbsp; I run a campaign with a lot of players, some of whom hang out on the splash page while I am working on other maps.&nbsp; The splash page has a world map covered with fog of war lighting (LDL), but when I change lighting on a different page (e.g., set it to UDL), the fog of war lighting on the splash page will be lost even when I changed nothing on that page.&nbsp; It is very unwelcome.&nbsp; I am not really interested in testing out why it's happening or how it's happening (though I guess I will have to), I would rather it just didn't happen.&nbsp;&nbsp;

Bob DM S. said: I saw another post this back in January, I am seeing the exact same issue.&nbsp; I'm having a problem with the dynamic lighting. In multiple games (all modules), my players will move their tokens and simply go blind. Like the dynamic lighting just turns off and they can't see anything. The only fix I've found is the turn off the dynamic lighting (revealing the whole map) and turn it back on, and even then they usually go blind the next time they move their token. So this is still an issue as of right now. I am working with a friend and trying to see what is happening. Using zoom to look at his computer and mine at the same time. Everything looks right on my computer, his is not working, the tokens lost all sight. If I turn off UDL save it, then turn it on everything comes back. Move a token and it is okay, then a minute later move a token and everyone goes blind again.&nbsp; Hey Bob, I had this same issue and thought in the past it may be tied to some tokens still having LDL values though that seemed to not be the case. Earlier in this thread this same issue also came up and it seemed tied to actually changing from one map to the other. As soon as the player view is changed and the new one has UDL on it has a chance to create this behaviour. With that I mean: Vision breaking entirely on that screen. You can indeed turn UDL off and on again for a short fix but then it does come back. The workaround that came up in this thread, and has helped me so far, is a reload of the browser tab. That seemed to have fixed it on every game I have run since finding out about this issue. Do note that this issue seems to be client side so every player and the DM will need to do this seperately when it comes up after changing a map. It is far but ideal, but it can maybe help you moving forward until the issue is fixed. Still agree though, it is quite jarring and annoying when it happens and just because there is a workaround that does not mean it is lower prio because of it. Your post just shows that more and more people run into it every week and this needs to be fixed as I believe this may be the main bug causing people to say UDL just doesn't work. All other things like Light multipliers and such are details compared to Lighting just breaking mid game because you had to change maps for the players. Changing from map to map is key functionality for Roll20 and one reason why I once got interested in this tool to begin with. It gives DM's a lot of control and that key functionality breaking UDL mid session is a big problem.&nbsp;

Hi! I just upgraded to Pro mainly to be able to use UDL, and while playing we had the bug of having some individual players not see other players and have their vision really dimmed, even if Day Mode is activated for the map. We are using the updated Lost Mine of Phandelver and Thundertree was very broken for us (although it was the map we were unsing when upgraded). Also, I didn't find a way to reset the explored areas on Explorer Mode . Having a button do this would be very valuable, since I have tried to move the tokens around for a bit offline inside Cragmaw Castle and now my players will be able to see the map layout from explorer mode the next session, before they even have gone in. Is there a way to do this already? Thanks and keep up the work, Xavi

Xavier G. said: Also, I didn't find a way to reset the explored areas on Explorer Mode .&nbsp; The reset is a little fussy. You use the reveal tool on the left-side palette, the one that looks like an eyeball.&nbsp; Then you have to make two menu choices: 1) either permanent darkness or explorable darkness, and 2) either hide areas or reveal areas, and then click on the last item, reset, which looks like a trash can.

Regarding "Reset Explorable Darkness",&nbsp; this seems to very consistently just break vision for players in my games. They'll just lose vision completely until either I turn off and on Dynamic Lighting, or they refresh the page for Roll20.

Making a copy of a map tends to reset explorable darkness on it as well (for both the original and the copy).&nbsp; Which is annoying - but I suppose another option for you? :)