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

1598406751

Edited 1598408347
Nyss said: <a href="https://i.imgur.com/jGYh7TA.png" rel="nofollow">https://i.imgur.com/jGYh7TA.png</a> I see no 4th option? Odd... it's certainly there on mine. Perhaps it's a different subscription tier....? Though I see we're both Pro tier... so, no clue.
Just adding my own feedback that if it's not intended for the option of Nightvision to have Dim Lighting attached, as per D&amp;D 5e, I really wish it would be.&nbsp; Thanks for having this thread.
Hey folks - not sure if this is the correct place but figured I'd start here.&nbsp; Long time Roll20 user (since 2013) - but took a couple of years off recently and returned to find this nifty new dynamic lighting coming along.&nbsp; I recently adjusted one of my games (using the converter tool) and suddenly - the page doesn't render at all for me on Firefox ( version 79.0 on top of Ubuntu 18 ) .&nbsp; When I bounce over to Chrome, it works fine.&nbsp; Legacy Dynamic Lighting works great on both browsers for me. So - my question:&nbsp; any settings within Firefox that need to be finger-fondled to get it working smoothly.&nbsp; I'm a Linux only user and typically fly Firefox for my Roll20.&nbsp; I can switch to Chrome...but shouldn't have to.&nbsp; Hopefully I'm not the only one with the issue. Much appreciate the work being done with it - the feature seems quite awesome (compared to the old manual way).&nbsp; Any guidance is most appreciated and/or any directions where such a question may already be answered or might be more appropriately posed. Cheers!
1598451836
keithcurtis
Forum Champion
Marketplace Creator
API Scripter
Nyss, Not sure why Andrew's screen shot looks different from yours, but if Update on Token Drop is not on the UDL panel, it should be on the Page settings panel (scroll down below the warning box).
Hey Nyss, Does that option only appear to be missing in one game? Does it appear if you create a new game? Additionally, have you attempted to disable extensions?
I recently created a map with the new lighting system for my players and it was a disaster. I had multiple people that could either: 1) See through barriers as if they are fully lit but with the large black diagonal slash through the middle of the screen, as seen in previous posts: 2) See multiple copies of tokens with skewed aspect ratios, as seen in previous posts - and also can see through barriers. &nbsp; All these players have no problems with the old dynamic lighting system. The above two cases were screenshots my players provided me. Luckily I had little confidence in the new system so I made my map without any possible spoilers for my players in case they could see through barriers, which half of them could.&nbsp; So far I am not impressed with the new system, as I attempted to create a single very simple dynamic lighting map and it was unplayable. I had correctly set all the token permissions, lighting distances, etc. The game this was from was the Eberron: Rising from the Last War game on my account, however I reverted all the map and token settings to the old versions so it would be playable. Back to the old system for me. Please do not force us to use this new system until it is working properly. Thanks P.S. It is obvious from other tools that the technology exists for proper dynamic lighting and fog of war. I have heavily invested in Roll20 and have no desire to switch to another tool, but we have gone from one failed system (unable to run dynamic lighting and advanced fog of war simultaneously) to another failed system (Broken dynamic lighting and fog of war). Progress is glacial. Feedback and transparency are limited. You offer premium subscriptions for services that do not currently work as expected. As a consumer I expect better.
Adam said: I recently created a map with the new lighting system for my players and it was a disaster. I had multiple people that could either: 1) See through barriers as if they are fully lit but with the large black diagonal slash through the middle of the screen, as seen in previous posts: 2) See multiple copies of tokens with skewed aspect ratios, as seen in previous posts - and also can see through barriers. &nbsp; All these players have no problems with the old dynamic lighting system. The above two cases were screenshots my players provided me. Luckily I had little confidence in the new system so I made my map without any possible spoilers for my players in case they could see through barriers, which half of them could.&nbsp; So far I am not impressed with the new system, as I attempted to create a single very simple dynamic lighting map and it was unplayable. I had correctly set all the token permissions, lighting distances, etc. The game this was from was the Eberron: Rising from the Last War game on my account, however I reverted all the map and token settings to the old versions so it would be playable. Back to the old system for me. Please do not force us to use this new system until it is working properly. Thanks P.S. It is obvious from other tools that the technology exists for proper dynamic lighting and fog of war. I have heavily invested in Roll20 and have no desire to switch to another tool, but we have gone from one failed system (unable to run dynamic lighting and advanced fog of war simultaneously) to another failed system (Broken dynamic lighting and fog of war). Progress is glacial. Feedback and transparency are limited. You offer premium subscriptions for services that do not currently work as expected. As a consumer I expect better. If other people are as frustrated as I am at the developers lack of transparency and their bull-headed approach to bulldozing LDL in favour of UDL when UDL is clearly unfinished and buggy as hell then I suggest that if you are a pro subscriber, that you email them directly as well as posting here on the forums. If they fail to provide a decent explanation of their thought process and their plans for the platform, I then suggest we migrate to twitter and quiz whoever runs their social media what in the nine hells they are playing at.
I assume this is a problem many folks have been having, but I just got in to prep for my weekly session this evening and got the "update to UDL" message.&nbsp; Using the tool, I assume all maps and tokens were converted.&nbsp; I say assume because as soon as I used the tool and tried to reenter the game (on the map that's currently in use by the player and I could see fine on just moments ago) I rec'd&nbsp;&nbsp;SBOX_FATAL_MEMORY_EXCEEDED errors.&nbsp; I ran thru the litany of standard "are you using the right browser" and "clear your cache" nonsense, and no joy.&nbsp; Every time I tried to enter the game it would begin the process of loading the screen... I could see the initiative tracker that was open, my face in the bottom and the right side window... but the main screen was black and then after a few seconds OOPs and&nbsp;&nbsp;SBOX_FATAL_MEMORY_EXCEEDED.&nbsp; So I rolled back to yesterday and can now enter my maps again.&nbsp; Clearly the tool and/or the UDL system are still heavily bugged.&nbsp; Hard crashes are not cool and I would suggest anyone converting think again before implementing until roll20 get's it's shizzle together.
Hello, I'm seeing a strange bug after I converted my game to the updated dynamic lighting. All the images set on the map layer are skewed and look like the following: Image with UDL off Image with UDL on: The superimposed image gets worse the further I zoom out. This occurs for every page (about 20 or so) in the page toolbar. Is the only current fix to go through each map and manually turn off UDL? Is there a way to turn it off for the whole game, just like the conversion tool turned it on? Thanks!
Sewer Crew Gaming said: If other people are as frustrated as I am at the developers lack of transparency and their bull-headed approach to bulldozing LDL in favour of UDL when UDL is clearly unfinished and buggy as hell then I suggest that if you are a pro subscriber, that you email them directly as well as posting here on the forums. If they fail to provide a decent explanation of their thought process and their plans for the platform, I then suggest we migrate to twitter and quiz whoever runs their social media what in the nine hells they are playing at. Completely agreed. The lack of updates for a release with this many bugs is irresponsible. In the last two days, I've seen 2 hotfixs posted...neither of them addressing the giant elephant in the room, but fixing mundane stuff like the charactermancer in a couple different games. Jason said: Hello, I'm seeing a strange bug after I converted my game to the updated dynamic lighting. All the images set on the map layer are skewed and look like the following: Image with UDL off Image with UDL on: The superimposed image gets worse the further I zoom out. This occurs for every page (about 20 or so) in the page toolbar. Is the only current fix to go through each map and manually turn off UDL? Is there a way to turn it off for the whole game, just like the conversion tool turned it on? Thanks! Jason, I had to completely abandon ship on my game and create a new game. Turning UDL off did nothing for me, so I created a new game without UDL
1598541993

Edited 1598542813
Brian C.
Pro
Marketplace Creator
Compendium Curator
In yesterday's roundtable: Corey and Jeff said that dim light darkvision is "near the top" of priorities to be fixed. <a href="https://www.twitch.tv/videos/722547946?t=0h20m15s" rel="nofollow">https://www.twitch.tv/videos/722547946?t=0h20m15s</a> Why is dim light darkvision not even in the list of known issues?
Brian C. said: In yesterday's roundtable: Corey and Jeff said that dim light darkvision is "near the top" of priorities to be fixed. <a href="https://www.twitch.tv/videos/722547946?t=0h20m15s" rel="nofollow">https://www.twitch.tv/videos/722547946?t=0h20m15s</a> Why is dim light darkvision not even in the list of known issues? And if it is a priority, why has no one from Roll20 said so in this current thread? All the Roll20 responses seem to be, "Can you send me a link to your game?" Which not only floods the thread with nothing (as another user previously stated) but also comes across as completely oblivious to the real and rising frustration of many Roll20 users.
Drespar said: Also, another quick update! (seemed&nbsp;more fitting in a smaller separate post) The dev team has been working with the forced field of vision issue that many of you are experiencing and we have a fix in the works! Keep an eye out for updates next week in the release notes and we will also let you know here. Still waiting on that " fix in the works ". You can't just say "Oh hey that issue you are all eager about .. we almost have a fix stay tuned" and then not say or fix anything. That's just placating your consumer base without real answers. Did you even have a fix in the works or did you just know you had to address it somehow because people were mad? It's starting to feel sneaky and disingenuous.
And what about low-light vision for game systems that still use it (i.e. PF1)? Still haven't seen that in the feature parity UDL. Or is Roll20 removing itself as system agnostic, catering to 5E and PF2 players?
I think an explicit statement that Legacy Dynamic Lighting will not go away until the bugs listed out in the first post of this thread are resolved*, would go a long way to mollify the unease expressed in this thread. *I assume this to be the case. Roll20 staff may be assuming that everyone is assuming this. Statements of intent are better than letting people assume, IMO.
1598554544
Brian C.
Pro
Marketplace Creator
Compendium Curator
Craig said: And what about low-light vision for game systems that still use it (i.e. PF1)? Still haven't seen that in the feature parity UDL. Or is Roll20 removing itself as system agnostic, catering to 5E and PF2 players? Does setting the Advanced Settings-&gt;Light Multiplier to 200% not work for you? Don't forget to check with a second account if Ctrl+L fails.
Thank you. When I tested that option last week, it wasn't working. Maybe it is because it was an older map previously set with LDL. It would appear that low-light vision is working. Made a quick test map with a character and a torch (both set with 10 ft of normal light and 10 ft low light, the character set with Light Multiplier at 200%). GM View Player View I'm hoping that the devs can update the separation along the edges between normal and low light. It's a bit easier to see in the Player View but especially hard to distinguish in the GM View. Here are a couple more screen captures with the background set to another color, so it's just not the background being used. GM VIew Player View Same map and tokens using using LDL settings GM View Player View Brian C. said: Craig said: And what about low-light vision for game systems that still use it (i.e. PF1)? Still haven't seen that in the feature parity UDL. Or is Roll20 removing itself as system agnostic, catering to 5E and PF2 players? Does setting the Advanced Settings-&gt;Light Multiplier to 200% not work for you? Don't forget to check with a second account if Ctrl+L fails.
1598571675
Brian C.
Pro
Marketplace Creator
Compendium Curator
It strikes me that a lot of issues would likely be resolved if the Night Vision was handled as a full-fledged light source instead of what is being done right now. The change can be as simple as a token having two light sources instead of one. If Night Vision was a light that only controlling players and the GM saw, the following happens: Potentially, the Night Vision cone bug goes away if the bug is in the code that is different from a normal light. Night Vision can provide dim light and blend correctly with other dim light sources. The two light sources could properly blend color with each other. Two light sources on a token allows situations like a torch and 60 feet of darkvision. The player controlling the token and the GM see 40 feet of bright light and 20 feet of dim light as the two sources combine. Everyone else just sees the 20 feet of bright light and 20 feet of dim light of the torch. While it would be more efficient to only run one light, potentially by just mathematically combing the numbers for the token's two light sources, having them separate makes color blending really easy. (More on that later.) This solution could be implemented really quickly and give your users what they want.
1598574341
Brian C.
Pro
Marketplace Creator
Compendium Curator
Color in Night Vision is currently handled with a tint. Because of how two Night Vision areas blend when they overlap, it is evident that this is using a subtractive blending process. In other words, it looks like what happens when you mix physical substances like paint. As an example, Night Vision mixes red and green to make brown. Light does not blend that way. It has an additive blending process. In the demo from&nbsp; <a href="https://corybeams.com/le/examples/#interactive_lights" rel="nofollow">https://corybeams.com/le/examples/#interactive_lights</a> , red and green make yellow. This approximates what you would get if you had a red and green light bulb next to each other. All of the light sources a player sees can be blended together first to create a light map. This can then be combined with an image built from the assets on the various VTT layers to show correct color when the items are in an area with lights that have a color other than white. Looking at&nbsp; <a href="http://www.nutty.ca/articles/blend_modes/" rel="nofollow">http://www.nutty.ca/articles/blend_modes/</a> , we can experiment with mixing light sources by setting the source and destination to color and the blending mode to "Add" (pixel = src + dest). Dim light can be simulated by reducing each of the three color bars on one of the lights to half of their values. Going back to the red + green example, we can make yellow. &nbsp;We can then combine that with the actual art on the VTT. The yellow light brings out some of the red and green in the image, grays and blues are not visible, because there is no blue light to draw them out. It would be great if UDL handled color blending of light sources like, well, light . However, speaking solely for myself, it is more important to have Night Vision functional with just white light that can properly handle dim light darkvision (and bright light devil's sight) for 5e and other systems. No sharpen effect. No color. Just functional Night Vision that works as well or better than it does in LDL. The nice part is, with Night Vision as just another light source, adding color can happen for Night Vision and regular light sources simultaneously, fulfilling another longstanding feature request.
PunyPaladin said: Nicholas said: PunyPaladin said: One of my player has 'god-level' vision.&nbsp; He can see everything on the token layer. I've taken away vision on his token entirely and that didn't fix it.&nbsp; Hey&nbsp;PunyPaladin -&nbsp; Can you provide me a link to this game, the name of the page, and the name of the characters Token/Journal entry this occurred with, please? We'll definitely take a closer look at what might be going on here. Thanks for the report!&nbsp; PM Sent Hey Nicholas, any update on this?&nbsp; Did you get my PM? Did you enter the game and see what I'm talking about? The game is Dungeon of the Mad Mage and the problem was experienced on Level 3 and level 5, i.e. all the levels we visited since "feature parity" was announced and I turned on UDL.&nbsp;&nbsp; Do you have a workaround of any sort?&nbsp;&nbsp;
1598620555
Caden
Forum Champion
Sheet Author
API Scripter
Compendium Curator
Greetings, I’m one of the devs now working on the new dynamic lighting feature. I’m newly assigned to this effort and I have been spending a lot of time discussing your input with our support team. We’ve taken that input and completed a risk assessment to evaluate the outstanding issues with new light. Dynamic Lighting performance issues Dynamic Lighting vision issues results Dynamic Lighting new features do not function as expected (usability issues) Dynamic Lighting feature parity is not complete These four areas cover the issues collected from this post and other bug threads. I’m reviewing this risk assessment every two weeks to keep tabs on the progress we’ve made. Going forward we plan to have another team member pop in here to provide regular updates on our challenges and successes. As you’re all acutely aware of, making the old virtual tabletop code work with the shiny new lighting feature continues to be a challenge. We’re actively updating the old and new code in order to make a future transition as painless as possible. Over the last two weeks we have done some extensive refactoring to improve our code health. This will allow us to fix difficult issues, make features run more efficiently, and help reduce the introduction of new issues when fixing old ones. Its not glorious work but it's needed for us to tackle the really challenging issues related to performance (risk 1) and bugs with Explorer mode (risks 2). This will continue to be the majority of our work for the next two weeks. We’ve also been working on the “cone” bug related to vision. This seemed like a simple fix at first but we discovered that fixing it interrupted other features. For example the vision cones started projecting in a counter-clockwise rotation instead of clockwise. :( We’re working through the puzzle pieces with delicate testing to minimize the risk of trading one bug for another. A few people here have mentioned the lack of low light for Night Vision and I want to assure you it’s on our list of items to address in the future. At the moment it’s on the lower end of the risk assessment, falling under #3 and #4. As a result I don’t have further details at this time but it continues to diligently be voiced as an area of concern in meetings by the support team on your behalf. :) - Cassie TL:DR We are working on the “cone” issue. The XP team are your faithful advocates. Devs are making steady progress on addressing Explorer Mode and Performance concerns. :) P.S. The 'tearing' effect Explorer Mode has, posted on this page by Adam, has been something I've been personalty working on for over two weeks now. It happens on Mac integrated graphics cards and some other specific hardware. I get it when playing on my Mac with Explorer Mode turned on. Its been challenging but I've made some progress. I'm not sure when I'll have it fully resolved but we've discovered useful information to the cause.
1598623360
keithcurtis
Forum Champion
Marketplace Creator
API Scripter
Thank you Cassie.
Thank you for the update. Appreciate the insight.&nbsp; :)
1598625212
Caden
Forum Champion
Sheet Author
API Scripter
Compendium Curator
You're welcome. :)
1598628819

Edited 1598628838
I've been having a look at UDL...I copied a map that was extensively set up for LDL and manually migrated it to UDL, just to make sure I didn't introduce any artifacts from the automatic converter. Apart from the bugs that I encountered that have been previously mentioned in this thread, cone vision, Ctrl-L not reproducing the player's view correctly for the GM (and very bizarrely at times, a completely black map for instance, tested against a dummy player account), it seemed to work fine(ish), but not in a robust enough way that would give me the confidence to use it in a real game. The consistency of the GM view, for instance, seemed all over the place. Let's hope that this turns out to be everything Roll20 hoped for. I do have some notes: 1) I couldn't find a UDL equivalent for the LDL feature 'Restrict Movement'...UDL does restrict movement but I couldn't find a toggle for it. All the light restrictions on my maps are physical restrictions too&nbsp;so this isn't actually a problem...until it is :D 2) I couldn't&nbsp; find a UDL equivalent for the LDL feature 'Enforce Line of Sight'. Again, as far as I can tell it appears to enforce it anyway. 3) The variance between Bright Light and Dim Light doesn't seem very pronounced, don't know what others think about that, and I couldn't find a way to get UDL to support the LDL 'dim light starts at a negative distance trick' for variant mood lighting.&nbsp; 4) UDL inconsistently resets the settings when the Bright/Dim light toggles are turned off, that seems like a usability no-brainer to fix.
Just one more person sounding in on the night vision UDL issue; I'm having the FoV issue even though I've hand-drawn in the DL lines on new maps. The only workaround so far, is to turn off night vision, set the character to emit 'dim light', and just ask the players to RP when their character shouldn't be able to see. That said, I am a new subscriber, so when I tried out the much-touted new DL feature, I sort of thought it would be a bit more... implemented, if they're saying it's hit 'feature parity' with the old system? That aside, I think roll20 is great and once they've hammered these issues out, it'll be that much more awesome. It will be great to hear about a fix, because I think this feature would be really cool once it's working right!
Just ran the conversion to UDL table option. Should have read this forum first. Seeing most of the same issues listed here, but the biggest PITA is that I can no longer drop tokens from character sheets onto the table. Looking into it further and it appears my character sheets no longer have tokens associated with them. That's a ton of sheets I now have to update manually to get the tokens back.
PunyPaladin said: PunyPaladin said: Nicholas said: PunyPaladin said: One of my player has 'god-level' vision.&nbsp; He can see everything on the token layer. I've taken away vision on his token entirely and that didn't fix it.&nbsp; Hey&nbsp;PunyPaladin -&nbsp; Can you provide me a link to this game, the name of the page, and the name of the characters Token/Journal entry this occurred with, please? We'll definitely take a closer look at what might be going on here. Thanks for the report!&nbsp; PM Sent Hey Nicholas, any update on this?&nbsp; Did you get my PM? Did you enter the game and see what I'm talking about? The game is Dungeon of the Mad Mage and the problem was experienced on Level 3 and level 5, i.e. all the levels we visited since "feature parity" was announced and I turned on UDL.&nbsp;&nbsp; Do you have a workaround of any sort?&nbsp;&nbsp; Hey&nbsp;PunyPaladin -&nbsp; I am investigating right now, but had some additional questions and just sent you a PM response with those questions - thanks for the follow-up! :)
So here is my encounter with this Cone bug: In this video, I demonstrate that two tokens with the same setting are outputting different results: <a href="https://youtu.be/9v5brfrxh2s" rel="nofollow">https://youtu.be/9v5brfrxh2s</a> Then&nbsp; keithcurtis &nbsp;suggested linking the token with a radius to the character sheet in hopes that the sheet would save the prefered line of sight. This video demonstrates how that played out: <a href="https://youtu.be/oEAmZul0Fgw" rel="nofollow">https://youtu.be/oEAmZul0Fgw</a> Here is the original thread I made, where I go into a tad more detail on this: <a href="https://app.roll20.net/forum/post/9123055/two-tokens-with-the-same-lighting-settings-produces-different-results/?pageforid=9123055#post-9123055" rel="nofollow">https://app.roll20.net/forum/post/9123055/two-tokens-with-the-same-lighting-settings-produces-different-results/?pageforid=9123055#post-9123055</a>
Naz said: Just ran the conversion to UDL table option. Should have read this forum first. I really, really wish that the so called tool would go away. It's just breaking people's games.
We'll I guess I'll be manually converting my game back to LDL now. Maybe you should consider removing this message from games until UDL is actually in working condition. Not everyone using Roll20 is going the scour the forms to see if UDL is actually working before switching over with this message telling them they should switch now. You're just going to upset your paying customers that would have never known this was an issue.
Sometimes my players get this circle of revealed area when they move on the map that goes past any walls and reveals the map (only on the map layer). They don't have vision there, but it shows it as explored area. Sometimes them relogging has fixed this, but sometimes it hasn't gone away until I reset the whole revealed area and then it takes away what they have already explored.. :/
PaOx said: We'll I guess I'll be manually converting my game back to LDL now. Maybe you should consider removing this message from games until UDL is actually in working condition. Not everyone using Roll20 is going the scour the forms to see if UDL is actually working before switching over with this message telling them they should switch now. You're just going to upset your paying customers that would have never known this was an issue. Exactly. I appreciate Cassie's detailed response, but some of the bad feeling is being generated by the contradictory messages coming from Roll20. There is a LOT of work to be done on UDL before it's ready to be rolled out. Telling users en masse to begin switching from Legacy shouldn't be happening now. In fact it shouldn't be happening at all until UDL is in much, much, much better shape.
Hey everyone, As Cassie had mentioned previously , we are still tackling the “cone” vision bug. We are still working hard to minimize the risk of trading bugs. Unfortunately, in spite of my hinting at the fix , this will delay the roll out for the time being. My apologies for over-promising on this resolution. All of that said, we are still working hard on this issue and have made a good deal of progress. As some folks have noticed [ 1 , 2 ], there is a connection to the number of tokens. Below is a screenshot of a test scenario we are running to push the limits of our fix.
1598645330
Brian C.
Pro
Marketplace Creator
Compendium Curator
If only someone had suggested this three weeks ago when the notification first showed up. . . and two weeks ago when the thread was changed. Brian C. &nbsp;said: Brian C. &nbsp;said: This is irresponsible. Given the number of game-breaking bugs still in UDL (and the conversion tool) and that many of the new versions of features have a detrimental effect on game play, who decided that a general broadcast that UDL is ready for primetime was a good idea? There are going to be a lot of people who do not follow these bug threads who are in for some nasty surprises. I&nbsp; posted this &nbsp;over a week ago. In that time, we have seen numerous accounts of paying customers losing game sessions and having their games corrupted by the conversion tool, entire maps revealed to the players, vision only revealing a small angle of the map, and games grinding to a halt. I dismissed that notification, knowing that UDL and the conversion tool are dangerous to use in anything but a test environment. . . and now it's back? Why has the notification been restored when the system is obviously still not ready? Software should be nearly bulletproof when it is released to production. UDL and the conversion tool are still in a state where they really belong on the Dev server, and they&nbsp; really &nbsp;should not have repeated notifications telling unsuspecting users to convert their games. If you dismiss the notification, it just comes back. Every time your refresh a game's launch page, it comes back. The only &nbsp;way to definitively stop the notification from appearing on a game's launch page is to run the tool. There is a sacrosanct rule in software (one of many): do not destroy or corrupt the data of your customers. When there is a bug that destroys or corrupts data, you immediately throw all hands on deck to fix it. Until then, you mitigate the damage, notify your customers of the problem, and keep them away from it. Pushing unsuspecting customers towards the problem is the opposite of that. Roll20, you can do better. You have known about these bugs for weeks (months for some) and still push your paying customers toward a system that can corrupt their game to the point where they lose game time to this, whereas if they had stayed with LDL, they would be having a great time. People come here to enjoy themselves, to have fun, to unwind from a stressful week. Please, turn off the notification, and don't push UDL until it is bulletproof.
Liking the new 'explorer mode' for town encounters.&nbsp; Was wondering if there is any way to add the toggle for other tokens not to see light emitted from a single token?&nbsp; So the individual players only see their own field of view.
1598655467
Brian C.
Pro
Marketplace Creator
Compendium Curator
Zachary W. said: Liking the new 'explorer mode' for town encounters.&nbsp; Was wondering if there is any way to add the toggle for other tokens not to see light emitted from a single token?&nbsp; So the individual players only see their own field of view. You may want to take a look at a few examples:&nbsp; <a href="https://roll20.zendesk.com/hc/en-us/articles/360044771413-Lighting-Vision-Examples-and-Setups#Any-System" rel="nofollow">https://roll20.zendesk.com/hc/en-us/articles/360044771413-Lighting-Vision-Examples-and-Setups#Any-System</a> Based on your question, it sounds like you have experience with Legacy Dynamic Lighting. In UDL, the Other Players See Light tick box is gone, with the two use cases split into Bright/Dim light that can be seen by any token with vision, and Night Vision that only provides vision for the player who controls a token. Players automatically only see vision provided by tokens they control, so the vision is already split into their own field of view. Which players can "see" through a token is controlled by the token settings or the settings of a linked character sheet, the same as in LDL. If that did not answer your question, it might be good to ask the question again in the Specific Use Questions forum in the future, as this thread is more for issues and bugs with the feature. I was not 100% sure if you meant not seeing light from a certain token, other tokens, or any tokens. A scenario that you are trying to create might help explain that.
Brian C. said: If only someone had suggested this three weeks ago when the notification first showed up. . . and two weeks ago when the thread was changed. Brian C. &nbsp;said: Brian C. &nbsp;said: This is irresponsible. Given the number of game-breaking bugs still in UDL (and the conversion tool) and that many of the new versions of features have a detrimental effect on game play, who decided that a general broadcast that UDL is ready for primetime was a good idea? There are going to be a lot of people who do not follow these bug threads who are in for some nasty surprises. I&nbsp; posted this &nbsp;over a week ago. In that time, we have seen numerous accounts of paying customers losing game sessions and having their games corrupted by the conversion tool, entire maps revealed to the players, vision only revealing a small angle of the map, and games grinding to a halt. I dismissed that notification, knowing that UDL and the conversion tool are dangerous to use in anything but a test environment. . . and now it's back? Why has the notification been restored when the system is obviously still not ready? Software should be nearly bulletproof when it is released to production. UDL and the conversion tool are still in a state where they really belong on the Dev server, and they&nbsp; really &nbsp;should not have repeated notifications telling unsuspecting users to convert their games. If you dismiss the notification, it just comes back. Every time your refresh a game's launch page, it comes back. The only &nbsp;way to definitively stop the notification from appearing on a game's launch page is to run the tool. There is a sacrosanct rule in software (one of many): do not destroy or corrupt the data of your customers. When there is a bug that destroys or corrupts data, you immediately throw all hands on deck to fix it. Until then, you mitigate the damage, notify your customers of the problem, and keep them away from it. Pushing unsuspecting customers towards the problem is the opposite of that. Roll20, you can do better. You have known about these bugs for weeks (months for some) and still push your paying customers toward a system that can corrupt their game to the point where they lose game time to this, whereas if they had stayed with LDL, they would be having a great time. People come here to enjoy themselves, to have fun, to unwind from a stressful week. Please, turn off the notification, and don't push UDL until it is bulletproof. Applause.....Quoted for truth. Sad to say Roll20, every single dev working on this project failed BIG TIME....and continue to fail with every day that notification remains on. The notification existed because the developers assured us parity had been achieved, they just admitted that is not true. I literally had to scrap an entire game and start a new one just to be able to play. I have a 50+ hour a week job, I have a wife and kids. What I don't have is time to pull ALL my handouts, characters, NPCs, monsters, maps from an old broken game to a new game without UDL. What I don't have is time to redraw all my light blocking walls on maps, to reload all my dungeons, etc. Yet....that's what I've found myself doing the last two weeks because the devs failed. To say that I am upset about that is a vast understatement.
Cassie said: You're welcome. :) Thank you for taking the time to write out a well-thought-out and verbose update that is on a more conversational level. You explicitly explained things and talked as if there wasn't an arbitary word count to stay under; you didn't skip words to make a sentence shorter. I am exceedingly glad you're now on the dev team for the UDL system, and I believe you genuinely read the responses instead of skimming through them. Thank you for your efforts, Cassie. They are appreciated, as are the efforts of the other team members what with refactoring the code (that's a big hassle and a lot of work).
Cassie said: Greetings, I’m one of the devs now working on the new dynamic lighting feature. I’m newly assigned to this effort and I have been spending a lot of time discussing your input with our support team. We’ve taken that input and completed a risk assessment to evaluate the outstanding issues with new light. Dynamic Lighting performance issues Dynamic Lighting vision issues results Dynamic Lighting new features do not function as expected (usability issues) Dynamic Lighting feature parity is not complete These four areas cover the issues collected from this post and other bug threads. I’m reviewing this risk assessment every two weeks to keep tabs on the progress we’ve made. Going forward we plan to have another team member pop in here to provide regular updates on our challenges and successes. As you’re all acutely aware of, making the old virtual tabletop code work with the shiny new lighting feature continues to be a challenge. We’re actively updating the old and new code in order to make a future transition as painless as possible. Over the last two weeks we have done some extensive refactoring to improve our code health. This will allow us to fix difficult issues, make features run more efficiently, and help reduce the introduction of new issues when fixing old ones. Its not glorious work but it's needed for us to tackle the really challenging issues related to performance (risk 1) and bugs with Explorer mode (risks 2). This will continue to be the majority of our work for the next two weeks. We’ve also been working on the “cone” bug related to vision. This seemed like a simple fix at first but we discovered that fixing it interrupted other features. For example the vision cones started projecting in a counter-clockwise rotation instead of clockwise. :( We’re working through the puzzle pieces with delicate testing to minimize the risk of trading one bug for another. A few people here have mentioned the lack of low light for Night Vision and I want to assure you it’s on our list of items to address in the future. At the moment it’s on the lower end of the risk assessment, falling under #3 and #4. As a result I don’t have further details at this time but it continues to diligently be voiced as an area of concern in meetings by the support team on your behalf. :) - Cassie TL:DR We are working on the “cone” issue. The XP team are your faithful advocates. Devs are making steady progress on addressing Explorer Mode and Performance concerns. :) P.S. The 'tearing' effect Explorer Mode has, posted on this page by Adam, has been something I've been personalty working on for over two weeks now. It happens on Mac integrated graphics cards and some other specific hardware. I get it when playing on my Mac with Explorer Mode turned on. Its been challenging but I've made some progress. I'm not sure when I'll have it fully resolved but we've discovered useful information to the cause. This is very welcome news - hope to hear more from you on your progress in the coming weeks.
Jay R. said: Exactly. I appreciate Cassie's detailed response, but some of the bad feeling is being generated by the contradictory messages coming from Roll20. There is a LOT of work to be done on UDL before it's ready to be rolled out. Telling users en masse to begin switching from Legacy shouldn't be happening now. In fact it shouldn't be happening at all until UDL is in much, much, much better shape. I spend a bit of time on the Roll20 FB and reddit pages and there are numerous posts daily asking what users have done wrong in trying to use the UDL conversion.&nbsp; Very few know about all of the issues listed here.&nbsp; Many are confused when I say there are lots of bugs still being worked through, dont use UDL yet.&nbsp; There are many users that dont look at the forums and are unaware that the conversion tool is going to destroy their game.&nbsp; Very few even realize they should make a copy of their game first as well.&nbsp; If roll20 dont remove the note, they shoud at least put a warning to make a copy of your game first. (or better yet, have the first line of code in the conversion tool automatically do a copy of the game.)
Farling said: kreppulun said: Issue with Night Vision and the Tint color.&nbsp; Character 1 can see character 2's night vision tint (arrow).&nbsp; Running as GM and hitting Ctrl+L to look through character 1's view on a converted map.&nbsp; Don't know if the player sees it or just me testing it. Ctrl-L doesn't work properly with UDL. Thanks.&nbsp;
Tristan said: Cassie said: You're welcome. :) Thank you for taking the time to write out a well-thought-out and verbose update that is on a more conversational level. You explicitly explained things and talked as if there wasn't an arbitary word count to stay under; you didn't skip words to make a sentence shorter. I am exceedingly glad you're now on the dev team for the UDL system, and I believe you genuinely read the responses instead of skimming through them. Thank you for your efforts, Cassie. They are appreciated, as are the efforts of the other team members what with refactoring the code (that's a big hassle and a lot of work). I, too, appreciate Cassie's thoughtful response. It's the best response I've seen from Roll20 in a long time. To Roll20: Cassie's responses should be the timely standard when something major is happening and your users are confused or upset.
As has been said by a bunch of others on this thread, UDL is, at best, inconsistent. At worst, unusable. Seriously, it’s really bad. I’m having to scramble to make my map usable for my players. You all have put so much time and resources into UDL, and it looks &nbsp;promising. But please please please focus your energy on fixing it before spending any time at all retiring the LDL.&nbsp;
I was double-checking some work I'd done in preparation for tomorrow's game, expecting that things were finally working (they had been, last time I'd checked) and I found myself presented with the darkvision issues on the pages I'm going to be using from Shrine of Tamoachan. One of the tokens works perfectly. The rest, not at all, or at best, they get the sliver of bright light. I was, and am, super frustrated by the amount of time I've spent troubleshooting and disrupting the immersion of sessions. I'm having problems even with legacy lighting. It's almost worse. I don't know what to do. But...if I enable UDL without converting the page, it works...sometimes. If the problem persists, it seems like toggling UDL off and then back on again restores the functionality. At least, I think. It's a little confusing with all the different lighting options. I'd much prefer one track that just...works, even if it isn't as feature rich.
For what it's worth, the updated lighting is having weird issues for me too. I experienced the overlapping token visions blocking DM's layer, I've experienced random places appearing like they're lit (though still blocked by walls). But the thing I'm experiencing that is the most irritating is that light sources that emit dim light actually darken areas of nightvision. The fact that nightvision can't be set to work exactly like 5E's Darkvision (which, for the record, doesn't increase dim light to bright light) is very bad. It needs toggles so that it can function for 5E and PF2, and further toggles to make it work for 3E, PF, and other systems. Here's the full text of Darkvision (I know you have it, it's in the basic rules): "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." The Dim Light creating shadows inside of night vision, and the nightvision tint being additive, makes it currently unusable for me. And it's a shame, because I really like how explorer mode works.
I am getting this in multiple campaigns.&nbsp; If I copy the same broken tokens to a new page they work fine but I can find absolutely no way to fix the map they're on once the light layer starts breaking.&nbsp; This is a SERIOUS problem.&nbsp; I just converted my campaigns and at complete random they will act like you have locked on limited light cone (even when you haven't) and it's always stuck at an extremely odd angle. PublishedAuthor said: I have never used the "limit field of vision" function (so I don't think one token inherited it from another) but today on some maps, my player tokens have a weird restricted angle of vision. I have reported it through the google spreadsheet as requested, but am also posting here. Weirdly, this is the case on some maps but not others in the same game (from different modules - all premade - Yawning Portal).&nbsp; &nbsp;
Well said.&nbsp; I may have to convert my campaign back to the old lighting method just because it is rendering maps unusable entirely.&nbsp; It's just too buggy.&nbsp; It's not in a place to remove the old method yet. Toby said: As has been said by a bunch of others on this thread, UDL is, at best, inconsistent. At worst, unusable. Seriously, it’s really bad. I’m having to scramble to make my map usable for my players. You all have put so much time and resources into UDL, and it looks &nbsp;promising. But please please please focus your energy on fixing it before spending any time at all retiring the LDL.&nbsp;
Just chiming in agreement that the lack of a 5E-compatible darkvision option is a big issue for me that would make me consider switching platforms. &nbsp;&nbsp;&nbsp;&nbsp;
As for the Nightvision cone bug: I deleted all light sources from my map, then added all player tokens of those players that have Nightvision, set up their vision, then readded all the light sources, this seems to have fixed the bug for at least the tokens with Nightvision that were present before the light sources were added, as soon as another token with Nightvision is added it, however, suffers from the bug. It is not as much a fix, but at least a temporary solution to some.&nbsp; Not sure if it works every time either, I have only done so to one map, but before I attempted that I tried it out on a test map to see if it would work and it worked there as well.