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

Updated Dynamic Lighting - Feedback Thread

Not sure what is going on here, but ive got a map and i have established the Dynamic Lighting edges/bounds. I made a door in that layer and put some tokens with darkvision/vision turned on, but when i move it (or just delete it), there is no visibility past the threshold of where the door was. I can move the token into and out of the room, the vision is fine, but its registering as if the "door" is still there (for lighting only, not movement), and as such, tokens cant see into the room: Very frustrating and only just noticed it an hour before the session. Any ideas?
Also, it seems that moving any token to the GM layer, makes it entirely invisible. Factors on the map: Very large map (almost 3000x3000px) 15+ tokens on the map No light sources are in the room where im doing this (if i ctrl+L on said token, it just shows pitch black) No tokens are in the room with vision/nightvision The token still exists, and can be selected, but it is literally invisible, so i have to remember where it is. GM layer opacity is at 50%
Update after playing around more: The lighting issue with there seemingly being an invisible dynamic lighting wall was resolved when i reloaded the page, and then re-added the tokens onto the page The "invisible on the GM layer" issue was actually seemingly caused by multiple tokens in the room having vision/nightvision on. Once i turned that off, everything worked fine. Seems clear that regardless of vision settings, NOTHING on the GM layer should be affected. Additionally, I noticed that turning off the vision settings for the monster tokens in the room also brought back the dithered edges to the player token's nightvision, whereas before i did that, the circle of their vision ended in a hard line.
What you were trying to do: Set up Updated Dynamic Lighting on a standard map. What happened: &nbsp;the shadows of the UDL seems to have created an imprint of themselves on the white background, generating sort of a ghost/mirrored effect. I ran some tests and this glitch seems to be connected to the tokens' sight radius. Steps to Reproduce: I set up the UDL lines and boundaries and put the tokens on the map, with the correct configurations. Browser &amp; OS info: Google Chrome, Windows 10 pro 64bit. Is WebGL supported by your browser? Yes, it is supported.&nbsp; latform: Win32 Browser User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 Context Name: webgl GL Version: WebGL 1.0 (OpenGL ES 2.0 Chromium) Shading Language Version: WebGL GLSL ES 1.0 (OpenGL ES GLSL ES 1.0 Chromium) Vendor: WebKit Renderer: WebKit WebGL Unmasked Vendor: Google Inc. Unmasked Renderer: ANGLE (NVIDIA GeForce GTX 1070 Ti Direct3D11 vs_5_0 ps_5_0) Antialiasing: Available ANGLE: Yes, D3D9 Major Performance Caveat: Supported&nbsp; Extensions:&nbsp; No &nbsp; ANGLE_instanced_arrays EXT_blend_minmax EXT_color_buffer_half_float EXT_disjoint_timer_query EXT_float_blend EXT_frag_depth EXT_shader_texture_lod EXT_texture_compression_bptc EXT_texture_compression_rgtc EXT_texture_filter_anisotropic WEBKIT_EXT_texture_filter_anisotropic EXT_sRGB KHR_parallel_shader_compile OES_element_index_uint OES_fbo_render_mipmap OES_standard_derivatives OES_texture_float OES_texture_float_linear OES_texture_half_float OES_texture_half_float_linear OES_vertex_array_object WEBGL_color_buffer_float WEBGL_compressed_texture_s3tc WEBKIT_WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_depth_texture WEBKIT_WEBGL_depth_texture WEBGL_draw_buffers WEBGL_lose_context WEBKIT_WEBGL_lose_context Game Link: &nbsp; <a href="https://app.roll20.net/campaigns/details/7087504/aventuras-em-tanosia" rel="nofollow">https://app.roll20.net/campaigns/details/7087504/aventuras-em-tanosia</a> &nbsp; Game Settings I just allowed players to import characters and enabled Character Sheet (Standard 5e by Roll20). Map Settings Are you using Legacy or Updated? Updated, I think. When I try to use Legacy, I simply can't give sight to my players. Were you using Explorer Mode or not? Using Explorer. Were you using Daylight Mode or not? No Daylight. Token Settings Two tokens had Darkvision60ft One token did not have Darkvision There was a lantern token, emitting bright light 30ft and dim light 30ft. Do you have Hardware Acceleration turned On or Off in your browser or system: No idea. I've never fiddled with this, I'd assume it is Off. Speedtest Results 6ms ping, 7.16mb download, 5,73mb upload.&nbsp; Console Log Residual image on the background.
Hello, system fixed or still bugged ?
Al Pacino said: Hello, system fixed or still bugged ? Look at the release notes for the 8th.&nbsp; Not one mention of UDL or optimization.&nbsp; Guess what folks.&nbsp; You will be stuck with UDL as it is now and they will retire LDL pretty quickly.&nbsp; They did it last year with AFOW and they will do it again this year with UDL.&nbsp; Sorry.&nbsp; That's why when my sub ends in January, they will not get another dime from me!&nbsp; I can't support a company that won't back up its product and provide the features as advertised.&nbsp; We went a year without AFOW in LDL and now we will go a year without UDL.
1599814502

Edited 1599815239
The bug with GM layer objects not being visible came up for me 3 weeks ago, and it's killing my use of Roll20- the GM layer is a fundamental part of the utility of Roll20, and the UDL effectively kills it at the moment, meaning I can't see what I'm doing...try running an encounter with Phase Spiders without use of the GM layer...(which is when I first found out about this bug)! For me this is the number 1 priority Roll20 should be fixing in UDL I should add that if it isn't, I'll be looking at migrating my Pro game to another platform, since recreating everything in a system that works is preferable to paying for a system which is impossible to use.
Hello everyone! In continuing our intentions of providing communication on our efforts and plans, we’ve got an update that is going to go over upcoming tasks, work since the last update, the UDL Conversion Tool, and a few other items. Two weeks ago we talked about risk assessment and using that to show our team’s current focus once again: Progress appears slow Performance issues New features do not function as expected Vision issues Most of the points here have not changed from our previous assessment, but an important one we would like to bring clarity on is progress appearing slow.&nbsp; Our team is working hard on the Known Issues list, but there is a mix of issues that require more thorough care and others that we are able to resolve more easily. We’re not shying away from tackling the tough stuff by any means, but we also want to give results that you all can see. The following are issues we hope to deliver on soon: Yellow box missing when hovering over Turn Order for UDL enabled tokens Rotation handle not working for groups with UDL enabled Objects on GM Layer are disappearing when Tokens with Night Vision overlap. Talking about fixes, we recently put out an update for the ‘Cone Issue’ on the 1st of September , but if anyone still encounters that issue please let us know. Previously there was an investigation around the ‘tearing’ effect in Explorer Mode that has affected a group of Mac integrated graphics users and other specific hardware. We’ve been able to identify this as a larger issue that requires precise attention and time to get it to a state we feel comfortable in delivering to you, but this will take further effort and there isn’t a clear time frame currently. The UDL Conversion Tool is another feature that brought forward several valuable concerns and bugs to the forefront that we would like to address. Feedback on the wording for the conversion tool has helped in realigning expectations when using the tool and the impact it can have on games. We recommend diving into the helpdesk article we have for the Convert Lighting tool to get a better grasp on usage of the tool. The Conversion Tool also helped bring valuable data and attention to the ‘Cone Issue’ that would occur when a sufficient number tokens were converted to the new system along with errors that could affect the json of the game after conversion. Both of these have been resolved and we appreciate the information and details provided by users. If you have any further feedback for the tool, we’re happy to hear from you and greatly appreciate any examples of issues that may be encountered when using it. Dynamic Lighting Feature Parity has been a recurring conversation which could use a little love and clarification to realign views on it. The legacy system had a workaround that allowed for a dark vision equivalent that was closer to emitting a light that others can’t see rather than being able to see without light. This was a very backwards method in logic and didn’t provide a ‘Rules as Written’ Dark Vision for many popular game systems. Our hope is to make optional settings that adhere more to ‘Rules As Written’ for those systems, but that is slated more as an enhancement than achieving parity by replicating the workaround and until we are able to provide that enhancement we’ll continue to improve the Dark Vision tinting. If there are systems that need the old workaround, please let us know so we can take that into consideration. Lastly, anxiety and uncertainty about Legacy Dynamic Lighting Sunset is a big topic that has been ambiguous at times. While there isn’t a date to provide, we fully have the intention to give generous forewarning once a date is established, and are still hard at work to ensure that Updated Dynamic Lighting is brought up to polish and provide a satisfying user experience with improved performance and less bugs. ~~~ Elizabeth
ElKatWilbrooke said: Our hope is to make optional settings that adhere more to ‘Rules As Written’ for those systems, but that is slated more as an enhancement than achieving parity by replicating the workaround and until we are able to provide that enhancement we’ll continue to improve the Dark Vision tinting. If there are systems that need the old workaround, please let us know so we can take that into consideration. Dungeons &amp; Dragons 5th Edition. If you don't consider the "workaround" to be "feature parity" than you have to come up with something else to replace it or this will be a deal breaker for a lot of people.
1599862519

Edited 1599864667
Brian C.
Pro
Marketplace Creator
Compendium Curator
ElKatWilbrooke said: Dynamic Lighting Feature Parity has been a recurring conversation which could use a little love and clarification to realign views on it. The legacy system had a workaround that allowed for a dark vision equivalent that was closer to emitting a light that others can’t see rather than being able to see without light. This was a very backwards method in logic and didn’t provide a ‘Rules as Written’ Dark Vision for many popular game systems. Our hope is to make optional settings that adhere more to ‘Rules As Written’ for those systems, but that is slated more as an enhancement than achieving parity by replicating the workaround and until we are able to provide that enhancement we’ll continue to improve the Dark Vision tinting. If there are systems that need the old workaround, please let us know so we can take that into consideration. Which systems could not be supported by using a light that only the player can see? That is essentially what spectral range night vision is (as opposed to intensity range night vision, which is close to Pathfinder's low-light vision). It is ludicrous to call the darkvision in LDL a "workaround" when it was presented as the correct method in Roll20's own documentation for years. From&nbsp; <a href="https://wiki.roll20.net/Dynamic_Lighting_Examples" rel="nofollow">https://wiki.roll20.net/Dynamic_Lighting_Examples</a> : If Roll20 implemented Night Vision as a second light source (with bright and dim light) that only the player could see from the start, we would have functional Night Vision now. We would have skipped the cone issue. We would have darkvision for D&amp;D and its relatives (now about 60% of what is played on Roll20). We would not have objects hidden on the GM layer or any of the other problems created by this new implementation of sight. One lighting system would be handling regular lighting and night vision.
"Realign views" is a verrrrry strange phrase. Is that a nice way of saying "We don't agree to disagree; rather we agree that you will agree with us?" Darkvision in DnD 5e is very clear. 60 feet of vision where dark is dim, and dim is bright. Period, the end. You can call the LDL method a workaround if you'd like... but it is effective. The result is darkvision. Darkvision tinting doesn't work. Just doesn't. I can't find the magic setting on tinting that makes it look like dim light. Maybe someone else has one? Do YOU guys have an official recommendation on that? I agree with you that defining vision as "light that gets emitted from a character that only that character can see" is bizarre. Acknowledged. But it worked . LDL allows me to effectively and accurately display not only what darkvision looks like to a PC, but it also lets me accurately and effectively display what darkvision overlapped with a visible light source looks like to a PC. How do I do that with tinting, exactly? This isn't an enhancement. Again, I have to ask... are the fundamental underpinnings of UDL such that properly dimmed vision is not possible? If so, tell us. This way, we'll stop griping. I will adjust my expectations accordingly... or "realign my view," as you put it. But if there is no massive roadblock, then I can only say that calling the standard functioning of a vision system as RAW "an enhancement" when it's part of the the single most popular gaming system on your service... ...is mystifying to me. Anyway, long answer short... yeah, there's a system that needs the old workaround. Dungeons &amp; Dragons, Fifth Edition.
1599873568

Edited 1599999041
Progress appears slow ...... I think one of the issues here is that many of your users are loosing trust that progress is being made.&nbsp; This is clear from the dozens of great simple ideas the suggestions forums that have been around for years.&nbsp; According to Roll20, many of them will be possible once UDL is implemented, but there are so many in there that cant be related. Give us a couple of other things requested along the way instead of "Market place UI" improvements that caused more bugs and wasnt really asked for. What would be nice is a list of things that you are working on and the priority, rather then constant comments of 'thats a good idea, we will look into it".&nbsp; That way you dont have the suggestions page with filled with comments of "when / are we going to get this feature" The Conversion Tool also helped bring valuable data and attention to the ‘Cone Issue’ Your comments around the conversion tool basically say that you didnt test it at all, and put it out there for us to test, without telling everyone that this is for testing only.&nbsp; So many users on FB and reddit have been constantly asking what they did wrong while using the tool, without knowing that it was broken.
1599881934
Oosh
Sheet Author
API Scripter
Dynamic Lighting Feature Parity has been a recurring conversation which could use a little love and clarification to realign views on it. The legacy system had a workaround that allowed for a dark vision equivalent that was closer to emitting a light that others can’t see rather than being able to see without light. This was a very backwards method in logic and didn’t provide a ‘Rules as Written’ Dark Vision for many popular game systems. How else can it work, out of interest? Darkvision allows creatures to see where there are no light sources . An artificial light source which only the player can see, originating from the player's location, would seem to be the only sane way to achieve this. If you dim-light the whole map with "background light" that only darkvision players can see, those players can see the entire map, DL lines permitting, to an infinite range. In 5e we have creatures that can see without the aid of photons striking the retina, but for some reason only to 60 feet. This makes no sense whatsoever, how exactly are you going to model this in a "forwards" way? The LDL solution seems pretty smart to me, since this is effectively what Darkvision does - if you think this is "backwards", perhaps we need more backwards thinkers working on UDL? How does a bat "see" in the dark? It emits energy and detects what bounces back. This is your artificial light source that only the "player" can see. You cannot have Darkvision in a place with no light, unless something is emitted. Emitting it from the player seems a no-brainer, as this handles the Range aspect at the same time. Again, very interested in how this can be modeled in a better way. LDL represented 5e darkvision just fine (with the exception of Devil's Sight), and appears to be the smartest way to handle it. I can't speak for other systems.
Oosh said: How else can it work, out of interest? Darkvision allows creatures to see where there are no light sources . An artificial light source which only the player can see, originating from the player's location, would seem to be the only sane way to achieve this.&nbsp; This is an excellent point.
ElKatWilbrooke said: The UDL Conversion Tool is another feature that brought forward several valuable concerns and bugs to the forefront that we would like to address. The Conversion Tool also helped bring valuable data and attention to the ‘Cone Issue’ that would occur when a sufficient number tokens were converted to the new system along with errors that could affect the json of the game after conversion. Both of these have been resolved and we appreciate the information and details provided by users. If you have any further feedback for the tool, we’re happy to hear from you and greatly appreciate any examples of issues that may be encountered when using it. It's obvious at this point that you pushed UDL live for test purposes. In short: Roll20 deliberately broke people's games to gather data. That is a shitty move if I ever saw one. I've been a solid supporter of this site for years, but the way you treat your paying customers is&nbsp;execrable. Why isn't UDL properly tested on the Dev-server?
1599917150

Edited 1599917727
Wizo
Plus
Hey! The dynamic lighting issue still exists but on a lesser scale. This is what it looked like before the update, and this is a screenshot of it taken today. It isn't nearly as bad, but there are still some weird triangle issues that appear.&nbsp; Just want to let you know that the update helped, but it didn't fix the issue entirely.&nbsp; This is addressed to @EIKatWilbrooke &nbsp;and the roll 20 team
1599918177
Kraynic
Pro
Sheet Author
Ravenknight said: Why isn't UDL properly tested on the Dev-server? I expect because not enough of us were actually testing it by running games on the Dev server.
1599924147

Edited 1599928161
Brian C.
Pro
Marketplace Creator
Compendium Curator
Kraynic said: Ravenknight said: Why isn't UDL properly tested on the Dev-server? I expect because not enough of us were actually testing it by running games on the Dev server. It is the job of a software provider, not the users, to ensure software is fit for purpose before releasing to production. The Pro users were given just a few weeks to test. The message was made loud and clear by Pro users on the Dev server that Dynamic Lighting, and later the Conversion Tool, were not ready for live and why. That feedback was ignored. Instead, the software was pushed on the general populace on the live server as if it was ready for prime time. While a user still can avoid UDL, most users would not have known that was a good idea based on the following messages, variants of which came up in social media, blog announcements, and site notifications. <a href="https://twitter.com/roll20app/status/1247947647153037314" rel="nofollow">https://twitter.com/roll20app/status/1247947647153037314</a> <a href="https://app.roll20.net/forum/permalink/9053854/" rel="nofollow">https://app.roll20.net/forum/permalink/9053854/</a> Every major Roll20 feature release for the last two years that I can think of (bar one, mentioned below) has had major, game-breaking bugs that are revealed after 5 minutes of use and are not fixed for months. Unlike downloadable software, you cannot defer updates, so Roll20 updates need to be bulletproof before they are moved to live, but this same scenario has happened again (Text Editor Update, I still have an outstanding bug that I ask to be fixed every 6 months or so) and again , part 2 (AFoW update, the previous time the Dynamic Lighting system was rewritten from the ground up, dropped features, and made AFoW unusable with Global Illumination) and again , part 2 (Animation, still has amazing upload times a year and a half later) and again , part 2 (My Audio / Bring Your Own Beat, great that Roll20 prioritized this with Fanburst shutting down, but it was still released well before it was ready) and again &nbsp;(WebRTC Update, made video chat unusable for me and my group for a year and then was fixed without fanfare by an update about 5 months ago. Yay!) and again , part 2 . (A New Light, our current situation) The Charactermancer is one feature release that I can think of where the feature was tested on the Dev server first , and most issues that made it to live were edge cases that were handled relatively quickly . However, my players and I had no need for it until you could level up , so that could be clouding my judgement. Even then, it seemed like most of the Charactermancer bugs were edge cases of special combinations of features. The other time Roll20 did well in this time period was the Token Bar update. This was necessitated from fallout over changes made (within the AFoW rewrite if I recall correctly) and is the one time in my recollection that Roll20 actually rolled back a poorly implemented feature, took it to the dev server, and used the Pros feedback to actually get it right before releasing it again to live.
1599927891
Kraynic
Pro
Sheet Author
Brian C. said: It is the job of a software provider, not the users, to unsure software is fit for purpose before releasing to production. Not all software is developed that way.&nbsp; Linux distros, for example, largely rely on volunteer testing.&nbsp; This is especially true for the ISO (install media) testing, because the developers aren't going to be able to test that sort of thing on the myriad combinations of hardware out there.&nbsp; It might just be that being exposed to (and participating at times in) that sort of development environment has made me more agreeable to this whole system being made public.&nbsp; I do agree that their labeling should have made much more clear that UDL was not finished, but I have no problems with it being made available.
1599929524

Edited 1599929637
Brian C.
Pro
Marketplace Creator
Compendium Curator
Kraynic said: Brian C. said: It is the job of a software provider, not the users, to ensure software is fit for purpose before releasing to production. Not all software is developed that way.&nbsp; Linux distros, for example, largely rely on volunteer testing.&nbsp; This is especially true for the ISO (install media) testing, because the developers aren't going to be able to test that sort of thing on the myriad combinations of hardware out there.&nbsp; It might just be that being exposed to (and participating at times in) that sort of development environment has made me more agreeable to this whole system being made public.&nbsp; I do agree that their labeling should have made much more clear that UDL was not finished, but I have no problems with it being made available. No, not all software is developed that way, but Roll20 is not FOSS, and not all Linux distros are volunteer. Red Hat Enterprise is going to make sure themselves that everything is reliable before a new version is released because they are the ones on the hook for the support contract. In contrast, Roll20 is a closed-source product with a clear demarcation between the company and its users. While API and character sheets are largely a volunteer effort, the core software is not created by a group of volunteers who have asked other volunteers to provide beta testing before a feature is released to live. This is a company of paid professionals. However, for some reason, someone keeps on pulling the trigger on features way &nbsp;before they are reliable and passing them off as ready to use. This has been an ongoing problem for years, with the same pattern of behavior. Someone is authorizing these initial releases of new features and is either unaware that the features are horribly broken or does not care about the impact to Roll20's users time and time again. Dynamic Lighting is a paid feature that should work, full stop. Even the "free" users often still&nbsp;pay for the features they have access to through marketplace purchases, and they therefore have a reasonable assumption that they should be able to use the products they paid for on a free subscription without service interruptions or game-breaking bugs.
Brian C. said: Kraynic said: Ravenknight said: Why isn't UDL properly tested on the Dev-server? I expect because not enough of us were actually testing it by running games on the Dev server. It is the job of a software provider, not the users, to ensure software is fit for purpose before releasing to production. The Pro users were given just a few weeks to test. The message was made loud and clear by Pro users on the Dev server that Dynamic Lighting, and later the Conversion Tool, were not ready for live and why. That feedback was ignored. Instead, the software was pushed on the general populace on the live server as if it was ready for prime time. While a user still can avoid UDL, most users would not have known that was a good idea based on the following messages, variants of which came up in social media, blog announcements, and site notifications. <a href="https://twitter.com/roll20app/status/1247947647153037314" rel="nofollow">https://twitter.com/roll20app/status/1247947647153037314</a> <a href="https://app.roll20.net/forum/permalink/9053854/" rel="nofollow">https://app.roll20.net/forum/permalink/9053854/</a> Every major Roll20 feature release for the last two years that I can think of (bar one, mentioned below) has had major, game-breaking bugs that are revealed after 5 minutes of use and are not fixed for months. Unlike downloadable software, you cannot defer updates, so Roll20 updates need to be bulletproof before they are moved to live, but this same scenario has happened again (Text Editor Update, I still have an outstanding bug that I ask to be fixed every 6 months or so) and again , part 2 (AFoW update, the previous time the Dynamic Lighting system was rewritten from the ground up, dropped features, and made AFoW unusable with Global Illumination) and again , part 2 (Animation, still has amazing upload times a year and a half later) and again , part 2 (My Audio / Bring Your Own Beat, great that Roll20 prioritized this with Fanburst shutting down, but it was still released well before it was ready) and again &nbsp;(WebRTC Update, made video chat unusable for me and my group for a year and then was fixed without fanfare by an update about 5 months ago. Yay!) and again , part 2 . (A New Light, our current situation) The Charactermancer is one feature release that I can think of where the feature was tested on the Dev server first , and most issues that made it to live were edge cases that were handled relatively quickly . However, my players and I had no need for it until you could level up , so that could be clouding my judgement. Even then, it seemed like most of the Charactermancer bugs were edge cases of special combinations of features. The other time Roll20 did well in this time period was the Token Bar update. This was necessitated from fallout over changes made (within the AFoW rewrite if I recall correctly) and is the one time in my recollection that Roll20 actually rolled back a poorly implemented feature, took it to the dev server, and used the Pros feedback to actually get it right before releasing it again to live. Well said, Brian. Frankly, the above Roll20 post is more of the same platitudes and corporate BS. "Realign our views"? Now LDL darkvision was never a feature in UDL, and they're working on a workaround? This is garbage. Roll20: put UDL back into development. Remove the conversion tool and conversion message from the frontend. Work on UDL and do not stop until there is TRUE feature parity with LDL AND performance is not abysmal. No crap, no prevarication, no "bugs dressed up as features", no customer gaslighting. Do your job. This is your product; we are paying customers. Stop making your customers work for free.
Oh, and by the way, whatever work you're doing on UDL is also messing up Legacy lighting in existing games. Last night, my players had multiple instances of not being able to see properly, not being able to control tokens they had access to, and had to quit, close tabs, restart, and run only Roll20 without any other tabs open in order for things to work. No, I will not file a detailed bug report. Fix your own damn product.
1599931625
Kraynic
Pro
Sheet Author
Except that Red Hat Enterprise (server, business, stable distro) is also generally using core software that has already run through Fedora (end user, more cutting edge over stability distro) which is volunteer tested. And Roll20 has some of the same hurdles to cross in the area of hardware compatibility without the benefit of upstream testing.&nbsp; They can't reasonably test all that on their own, no matter our preferences. I doubt you are willing to agree with that, and that is fine.&nbsp; We obviously have different perspectives on this particular issue.&nbsp; The only thing I take issue with is the way the labels have been worded, since they didn't make clear enough that the new features were still definitely in testing.&nbsp; And dynamic lighting (at least the way I have been using for the last couple years) still works fine.&nbsp; There has been zero impact on my own games through this whole process with UDL, which probably also affects my view on things.
1599935723

Edited 1599936392
Brian C.
Pro
Marketplace Creator
Compendium Curator
Kraynic said: Except that Red Hat Enterprise (server, business, stable distro) is also generally using core software that has already run through Fedora (end user, more cutting edge over stability distro) which is volunteer tested. And Roll20 has some of the same hurdles to cross in the area of hardware compatibility without the benefit of upstream testing.&nbsp; They can't reasonably test all that on their own, no matter our preferences. I doubt you are willing to agree with that, and that is fine.&nbsp; We obviously have different perspectives on this particular issue.&nbsp; The only thing I take issue with is the way the labels have been worded, since they didn't make clear enough that the new features were still definitely in testing.&nbsp; And dynamic lighting (at least the way I have been using for the last couple years) still works fine.&nbsp; There has been zero impact on my own games through this whole process with UDL, which probably also affects my view on things. No, I do agree with you on much of what you say. Red Hat leverages Fedora's development. Roll20 can't check every scenario. However, the bugs that come out within the first couple hours of a bug thread being opened are often so easy to encounter and game breaking that it really makes it look like the prevailing attitude is, "It compiles, Ship it!" Additionally, the feedback for A New Light and the Conversion Tool on the Dev server was a solid, "This is not ready." That was ignored. I am glad UDL has consistently worked for you. Even as recently as last month, converting a marketplace product did not produce good results , and that was largely without testing player tokens, where many of the bugs listed in the threads are produced. I have a lot more to say, but it is pretty tangential to this particular dialogue. Thank you for the discussion. :)
1599939171
Kraynic
Pro
Sheet Author
Brian C. said: I am glad UDL has consistently worked for you. Actually, I still run games using the legacy system.&nbsp; I have copies of them that have been converted to UDL, but I haven't been confident enough of the conversion to just switch over on the primary version of the games.&nbsp;
I have about 4 to 5 players, each emitting light in a map with dynamic lighting, explorer mode on, and daylight mode off. Before the update the tokens all moved super smoothly and finely, but after the update they all move with a lot of lag.
1599945472
Brian C.
Pro
Marketplace Creator
Compendium Curator
I will say, "Thank you, Roll20, for finally allowing the UDL update notification on games to be dismissed."
1599945814

Edited 1599945877
Oosh said: Dynamic Lighting Feature Parity has been a recurring conversation which could use a little love and clarification to realign views on it. The legacy system had a workaround that allowed for a dark vision equivalent that was closer to emitting a light that others can’t see rather than being able to see without light. This was a very backwards method in logic and didn’t provide a ‘Rules as Written’ Dark Vision for many popular game systems. How else can it work, out of interest? Darkvision allows creatures to see where there are no light sources . An artificial light source which only the player can see, originating from the player's location, would seem to be the only sane way to achieve this. If you dim-light the whole map with "background light" that only darkvision players can see, those players can see the entire map, DL lines permitting, to an infinite range. In 5e we have creatures that can see without the aid of photons striking the retina, but for some reason only to 60 feet. This makes no sense whatsoever, how exactly are you going to model this in a "forwards" way? The LDL solution seems pretty smart to me, since this is effectively what Darkvision does - if you think this is "backwards", perhaps we need more backwards thinkers working on UDL? How does a bat "see" in the dark? It emits energy and detects what bounces back. This is your artificial light source that only the "player" can see. You cannot have Darkvision in a place with no light, unless something is emitted. Emitting it from the player seems a no-brainer, as this handles the Range aspect at the same time. Again, very interested in how this can be modeled in a better way. LDL represented 5e darkvision just fine (with the exception of Devil's Sight), and appears to be the smartest way to handle it. I can't speak for other systems. Indeed! In D&amp;D 5E, the darkvision is a grey-scale light emitting from the token that only the token can see. I don't know of any game systems where something similar would not occur. Pathfinder low-light vision is probably a form of light also, but doesn't only affects dim light and better, not actual darkness. But strangely, Pathfinder darkvision works in magical darkness while D&amp;D 5E darkvision doesn't work in magical darkness (although roll20 doesn't have the ability to create magical darkness, or does it, I might be getting confused with foundryvtt).
I'm having exceptional difficulties with the new lighting as my web browser slows down tremendously, especially when loading a new map, even new maps that aren't that big. It's crashing both roll20 and also either Discord or Zoom (depending on which audio I'm using.) Everything slows to a crawl, even when I've disabled all of my extensions and cleared by cache.&nbsp;
Hello everyone I apologize immediately for my terrible English ... as I began to mess around with the Updated Dynamic Light I noticed that the DM level is affected by the Dynamic Light. Players don't have this problem, but I can't quite see what's placed in the DM level if there are more than one Night Vision Player, with a Player shining Light back visible, but it's limited to the Player's vision and goes to fade where the light becomes dimmer...here are some pictures the opacity of the DM layer is 50%, the room is dark. In the corners there are two oozes, at the moment they are positioned on the DM level because they are spread on the wall and hidden from the view of the Players (when they notice their presence I will move them from the DM level to the Token level) if I bring in one Player whit&nbsp; Dark Vision, my vision becomes more rarefied If I bring in two or more Players whit Dark Vision, I don't see anything on the DM Level But, if I let in a Player who emanates Light (in this case the token emits Intense Light 6m and low Light 3m) the DM Level becomes visible again, but only in the lighting area of ​​the token I can't just rely on the vision of Tokens emitting Light, is there a way to solve this problem or is it one of those problems that still need to be fixed?
1600091934

Edited 1600091951
keithcurtis
Forum Champion
Marketplace Creator
API Scripter
Thanks Devil, That's a known issue and one of the higher fix priorities at the moment. I don't know if there's a good workaround at the moment.
I agree with much of the criticism that has been leveled at Roll 20 in these posts. UDL has been a mess from the get go. However, I do want to pause and say that I very much appreciate the effort Roll 20 is making to improve communications with us. If all they get in response is more attacks, I fear they may go back to the cone of silence. Getting regular posts like the one above is a positive move and it is appreciated. Even if I don't 100% agree with everything stated, I am super pleased to have it. The effort shows me that they are listening and attempting to improve the situation.&nbsp;
1600111812
Caden
Forum Champion
Sheet Author
API Scripter
Compendium Curator
Justin M. said: I agree with much of the criticism that has been leveled at Roll 20 in these posts. UDL has been a mess from the get go. However, I do want to pause and say that I very much appreciate the effort Roll 20 is making to improve communications with us. If all they get in response is more attacks, I fear they may go back to the cone of silence. Getting regular posts like the one above is a positive move and it is appreciated. Even if I don't 100% agree with everything stated, I am super pleased to have it. The effort shows me that they are listening and attempting to improve the situation.&nbsp; Thanks Justin. :) I appreciate the consideration. I can't change the past but we're making an effort to provide a better experience going forward.&nbsp;
I am still getting the mac related issue of a black strip accros my screen all other threads indicating this bug seem to be closed. is this still actively being addressed?
1600132011
Stephen C.
Pro
Sheet Author
I'm not sure if this is a known issue or not (I can't imagine it isn't), but when I control two tokens as a player and move them in the same select group, the map is completely lit up very briefly for dynamic lighting. In explorable darkness, that essentially reveals the entire map. The tokens that I were moving were different sizes, and they were being moved while they were on top of each other.
1600181579

Edited 1600182630
Windows 10 1909, Firefox 80.0.1 (64-bit), Hell's Rebels Campaign, Created new map with new tokens ========================================================= Green Guy = Vision + Night Vision 30 ft Red/Silver = Vision + Vision Multiplier 200% Dragon = no UDL options enabled When I select group and move, what the tokens see is shifted to upper left corner while I move the tokens (i.e the players can view that new location). When I release the tokens at their new location, the vision stays in the upper left corner, while sometimes it updates to the tokens' new location. When it does stay in the upper left corner, it stays there until I switch tabs in my browser and then it updates to the tokens' new location. ========================================================= Green Guy Token = Vision + Night Vision 30 ft + Bright Light 10 ft + Low Light Vision 10 ft Silver/Red Token = Vision + Light Multiplier 200% Used Ctrl+L to see what the tokens can see. The distances seen are far more than what the token should be allowed. Regarding the green guy with Night Vision + Bright + Low Light, that could be a character with Darkvision carrying a small light for his human friends. This character should see out to 30 ft max, as the Night Vision extends beyond the Bright Light and Low Light settings (10 ft + 10 ft = 20 ft). This took me 5 minutes to find this bug. I'm done being your QA tech, especially when I'm paying for your service.
I am noticing that tokens are seeing Past thier normal vision restrictions. And when I add light sources they are seeing even more area which should not happen.
ElKatWilbrooke said: Dynamic Lighting Feature Parity has been a recurring conversation which could use a little love and clarification to realign views on it. The legacy system had a workaround that allowed for a dark vision equivalent that was closer to emitting a light that others can’t see rather than being able to see without light. This was a very backwards method in logic and didn’t provide a ‘Rules as Written’ Dark Vision for many popular game systems. Our hope is to make optional settings that adhere more to ‘Rules As Written’ for those systems, but that is slated more as an enhancement than achieving parity by replicating the workaround and until we are able to provide that enhancement we’ll continue to improve the Dark Vision tinting. If there are systems that need the old workaround, please let us know so we can take that into consideration. Lastly, anxiety and uncertainty about Legacy Dynamic Lighting Sunset is a big topic that has been ambiguous at times. While there isn’t a date to provide, we fully have the intention to give generous forewarning once a date is established, and are still hard at work to ensure that Updated Dynamic Lighting is brought up to polish and provide a satisfying user experience with improved performance and less bugs. ~~~ Elizabeth Bold for emphasis is mine. I agree, that LDL "darkvision" was a work around, and a nuisance but it worked and I have no idea how this didn't work "rules as written" for games like D&amp;D and Pathfinder... but let's not get into the weeds here but perhaps some clarity could be said here with an example? Oh yeah, there is anxiety about LDL Sunset. Roll20 Subs.... do you feel this post alleviates these concerns? The tone I get from here is: Brace yourselves, UDL will not do everything LDL could do and make your peace with that.
Hello! The following fixes should now be live: Objects on GM layer are disappearing when Tokens with Nightvision overlap them Rotation handle does not work for groups when UDL is enabled UDL based tokens are sometimes not showing the yellow box indicating turn order @Sean S. In regards to the Mac Issue with the Black Bar, we still have plans to address and solve that issue. The Known Issues list has also been updated to include: 'Spinning a Group of Tokens the light cone is off-center'
ElKatWilbrooke said: Hello! The following fixes should now be live: Objects on GM layer are disappearing when Tokens with Nightvision overlap them Rotation handle does not work for groups when UDL is enabled UDL based tokens are sometimes not showing the yellow box indicating turn order @Sean S. In regards to the Mac Issue with the Black Bar, we still have plans to address and solve that issue. The Known Issues list has also been updated to include: 'Spinning a Group of Tokens the light cone is off-center' I still can't grab a handle to rotate, unless I am doing something totally wrong. Any ideas? I can use the resize handles, but not the rotate handle
Fixe the beast plz :)
1600244212
Sad
Sheet Author
API Scripter
Always get error, Player see through the map
Apologies for the delay but only just came across this, in response to the question: If there are systems that need the old workaround, please let us know so we can take that into consideration. Dungeons and Dragons 5th edition needs the old approach to be able to replicate Darkvision.
1600263764

Edited 1601224273
Sewer Crew Gaming
Marketplace Creator
Francesco said: Apologies for the delay but only just came across this, in response to the question: If there are systems that need the old workaround, please let us know so we can take that into consideration. Dungeons and Dragons 5th edition needs the old approach to be able to replicate Darkvision. This. Not sure if it's funny or sad that they didn't realise they were shooting themselves in the foot majorly here, for no real benefit. D&amp;D 5th edition is about 60%* of the games played on the platform, and they want to can LDL, ruining the dynamic lighting for those users? Not a very sound plan. Edit: edited my original post for accuracy.
My performance while using UDL with Dungeon of the Mad Mage is simply awful. I'm sure that it's related to the sheer size of the maps, but it's not like I am using a non-Roll20 product here. I've been spending a lot of extra time dividing the maps into smaller sections and using an API to teleport players between them, but it seems like a glitchy solution and definitely not viable long-term. I have already removed all vision from all non-player tokens. Moving a token takes 2-5 seconds to respond. Scrolling the map has a 1-2 second delay before anything happens. Loading the map takes 5-10 seconds. Is there anything I can do to improve performance?
1600272197
Kraynic
Pro
Sheet Author
Sewer Crew Gaming said: D&amp;D 5th edition is about 90% of the games played on the platform D&amp;D players may feel like they are 90% of the user base, but each time numbers are published, it is more like 50-55%.&nbsp; Don't marginalize those of us that play other systems more than we already are!&nbsp; :p
Kraynic said: Sewer Crew Gaming said: D&amp;D 5th edition is about 90% of the games played on the platform D&amp;D players may feel like they are 90% of the user base, but each time numbers are published, it is more like 50-55%.&nbsp;&nbsp; <a href="https://blog.roll20.net/post/617299166657445888/the-orr-group-industry-report-q1-2020" rel="nofollow">https://blog.roll20.net/post/617299166657445888/the-orr-group-industry-report-q1-2020</a> Very true.
1600280767

Edited 1600280804
Sewer Crew Gaming said: Francesco said: Apologies for the delay but only just came across this, in response to the question: If there are systems that need the old workaround, please let us know so we can take that into consideration. Dungeons and Dragons 5th edition needs the old approach to be able to replicate Darkvision. This. Not sure if it's funny or sad that they didn't realise they were shooting themselves in the foot majorly here, for no real benefit. D&amp;D 5th edition is about 90% of the games played on the platform, and they want to can LDL, ruining the dynamic lighting for those users? Not a very sound plan. The same is true for Pathfinder 1st Edition. I know this is considered a "dead" system now by many, but there are still a lot of players out there that haven't converted another system yet. My group will probably continue with this edition for at least another 2-3 years, if not longer because there are still Adventure Paths we haven't played/ran yet.
Craig said: Sewer Crew Gaming said: Francesco said: Apologies for the delay but only just came across this, in response to the question: If there are systems that need the old workaround, please let us know so we can take that into consideration. Dungeons and Dragons 5th edition needs the old approach to be able to replicate Darkvision. This. Not sure if it's funny or sad that they didn't realise they were shooting themselves in the foot majorly here, for no real benefit. D&amp;D 5th edition is about 90% of the games played on the platform, and they want to can LDL, ruining the dynamic lighting for those users? Not a very sound plan. The same is true for Pathfinder 1st Edition. I know this is considered a "dead" system now by many, but there are still a lot of players out there that haven't converted another system yet. My group will probably continue with this edition for at least another 2-3 years, if not longer because there are still Adventure Paths we haven't played/ran yet. D&amp;D 5e, D&amp;D 3.5, Pathfinder 1e and 2e, and Starfinder are all top ten games that use Darkvision largely the same way. These user accounts add up to 64.04% according to the ORR report. That is a lot of games UDL will no longer be able to support.
I'm running into a weird interaction with dim light. The selected token has 60 ft nightvision. The torch is emitting 30 ft of bright light and 30 ft of dim light. When the dimlight overlaps with the nightvision, the light is dimmed. This is unusual. It should be as bright as the night vision radius, dim light shouldn't dim the light. The 5E D&amp;D Darkvision language is: "You can see in dim light within 60 feet of you as if it were bright light, and in darkness as if it were dim light. You can't discern color in darkness, only shades of gray." So darkvision shouldn't be doubling the range of light (that's how low-light vision worked in 3E). Darkvision should be a range of distance where dim light is improved to bright light and darkness is improved to dim black and white. If 50% of the player base playes 5E, then it's a feature that should be able to be done rules as written.