Gold said:

Isn't that intended, that you can put building lights on the Map Layer? You're wanting to make every Campfire & Street Lamp & Chandalier & Spotlight into a Token and not a map object? (Asking Keith)

keithcurtis said:

Vision and light settings of any element on the Map layer should have no effect on the play experience. Only token and DL layers.

That's what I thought too.  I definitely want stuff on the map layer creating light.

I could see a case being made for things on the map layer not having vision.  Giving your scenery vision probably isn't going to result in any sort of desired behavior.  But I'd still probably rather the token honors the vision toggle should I have it set.

Historically, a GM has been able to place a player-controlled token on the map layer to provide vision without allowing the player to move the token.

Joseph B. said:

Had a similar experience just tonight.

Map had Dynamic Lighting turned on, all Legacy settings turned off. Set GM Darkness Opacity to 0 so I can see the whole map clearly.

Player Tokens had Vision and Night Vision turned on 60/blue/Dimness/30, legacy features off. Looked fine when I tested it solo in Player Mode (Ctrl-L). Only thing I would have said was off was that the alpha channels of the night vision for all the players were additive, contributing to an almost solid blue night vision colour so I could only see their section of the map when viewing from Player Mode (Ctrl-L). Which I could live with if... the rest worked.

The evening of, my players log on, and the map shows up fine for them... until someone moves their character token. Then the only thing that everyone can see is a greyscale area (no saturation) where there should be a blue alpha overlay, and no one can see any tokens at all, including their own. The effect resets for the players and works if they refresh their browser tab; for me the GM it resets to what it's supposed to be if I tab to another map and back again. Until... just one person or the GM moves a token... then everything is messed up again, no blue overlay only greyscale, and no one can see any tokens.

So I would say that this is not feature complete. This is not a 1.0 release. Please let us know when it is.

Hi Joseph, I have had this experience too and it seemed to be caused by some tokens still having values in their LDL values. As soon as I removed those values from all tokens on the map, this no longer occured. I posted about it earlier in this same thread.

Had this 2 weeks ago in a session at a map, all players had this problem at the same time. Two weeks later we picked up another session after removing all the LDL values from all tokens and we had zero issues the whole session.

Considering most tokens you can drag in from compendium still have the old values entered, this is quite annoying and means as a DM you have to stay on top of it. But this workaround so far has worked 100% of the time for me, even when recreating the exact same map and players as where the issue occured earlier. 

This item was on the 'under investigation' list of the devs, but I think this specific issue causes a lot of bad experiences with people going to UDL now with the announcement of sunsetting and trying it out again. I hope the team makes this a high priority issue just to stop the really bad first experience of people trying to swap now. It is a relatively new issue though, as I did not have this in sessions before february.

But you are right, not seeing anything is gamebreaking, and if you don't know the workaround you just come back with a horrible (first) experience after trying to convert.

Re: Map layer

You are all correct (or half correct). Which is also to say that I am wrong (or half wrong). Light is OK. Night Vision is not. UDL treats vision differently for the GM. It displays night vision fields for NPCs. If 20 goblins are in a dark room, it is now impossible for a GM to see if the room is lit. The solution is either to accept this or turn off NPC vision unless you need it. If a map image has night vision set, it creates confusion for the gm, since there appears to be a light source, but it serves no purpose. I'll edit my post, and thanks all for the catch.

Edit: Post is edited. Looking back, I started out fine. I only added the spurious light statement in the conclusion. Again, thanks all.

Hmm, I still think lighting/vision/night vision should apply on the Map Layer as well. NPCs in general should not have vision/Night Vision to avoid the performance hit, and if there were 20 goblins with darkvision in LDL, the room's light would be inscrutable to the GM as well. Besides that, things like magical scrying, bread crumbs, remote cameras, etc., should be on the map layer to give the player vision/Night Vision without letting the player move the token.

But you can always create token that are not in player control, why would you need to put those on the map layer?

Falk said:

But you can always create token that are not in player control, why would you need to put those on the map layer?

That's a good point. That swarm of goblins would generally be on the GM Layer or Token Layer rather than the Map Layer.

Kenton said:

João Luiz G. said:

2. It is really hard to see where bright light ends and where dim light begins (this was pretty clear with LDL)

With Updated Dynamic Lighting, you can choose the brightness level that works best for your preference. Katie Mae says more about that earlier in this thread. 

But isn't that otpion only avaliable for "Token Emits Light"? Couldn't find it under Night Vision... Thanks anyway.

Yeah, as a GM if I put any one token down, I can see out of that token initially. If I move the token, I can no longer see out of any tokens. Regardless of any settings combination I try. My players say that they can still see fine.

Edit to add: I ran convert to dynamic lighting again for one game, it appears to work again at least temporarily. I will try to convert, again, my other games that I have lost sight in.

2nd Edit: Running the conversion again on one of my games appears to have fixed all of them.

I was one of the guys who express his concerns about the new UDL. But now Im here to congrats you with the way thinks are goind. Teste 2 games with UDL and both of them work properly. Really appreciate your great work, and I hope you could meet your development deadline properly.

am i the only one bothered by the selective responses of the roll20 team in this thread and feeling ignored?

is it always been like this with the staff?

For instance, why is it so hard to get a reply to something like this?

Joshua V. said:
Do we have word yet on when there will be full API support for UDL? I still can't assign or modify the dimming/sharpening effect.

I would understand if there was no reply at all from the staff in this thread, but they are here, they read the posts, they reply to a few things... and they just ignore the rest of us? 

Katie Mae said:

Hi everyone! A few things before the weekend:

We have been doing internal testing on the Dev Server this week for an update that optimized Firebase data usage. We expect this update to go live early next week. This is a necessary restructure that won’t impact most users, but may reduce lag for those with the very worst of conditions. 

Also, Wil, in regards to your latest post: I have been working with the QA Team to reproduce these steps and have been unable to do so. What would help us the most here in finding a cause is to provide reproduction steps from start to finish. What we are looking for would be something like:

1. Create a new game using X module/addon
2. Use, or do not use, convert lighting tool
3. Set up a particular page/new page with these lighting settings
4. Set up tokens with these lighting settings
5. Take these actions to cause the issue

A beginning to end breakdown with a fresh game of how to cause the issue to occur it would be extremely valuable.

Have a good weekend, folks! (: 

In incognito mode in chrome with no plugins:

1) Create New Game (no Char Sheet)

2) Create New Page (Untitled)

3) Turn on Dynamic Lighting and Explorer Mode on "Untitled"

4) Switch to "Untitled"

5) Drag an image to the page (torch or whatever)

6) Edit torch token

6a) Toggle "Bright Light" (5ft) on the "Dynamic Lighting" tab

7) Drag another image to the page (pirate or whatever)

8) Edit Pirate token

8a) Select "All Players" in "Controlled By"

8b) Enable "Vision" in "Dynamic Lighting" tab

8c) Enable "Night Vision"

8d) Set a radius of 60ft to make it obvious when things get all broken

8e) Set a tint color to make it obvious when things get all broken

9) Switch to "Start" page

10) Switch to "Untitled" page

11) Move pirate token

Angelo said:

am i the only one bothered by the selective responses of the roll20 team in this thread and feeling ignored?

is it always been like this with the staff?

For instance, why is it so hard to get a reply to something like this?

Joshua V. said:
Do we have word yet on when there will be full API support for UDL? I still can't assign or modify the dimming/sharpening effect.

I would understand if there was no reply at all from the staff in this thread, but they are here, they read the posts, they reply to a few things... and they just ignore the rest of us? 

I think the case here is that the team that works on UDL is not necessarily the team that exposes facets of the codebase to the API. It's also possibly the person reporting here doesn't know, of for some reason cannot comment on it authoritatively. Yeah, its annoying (scroll up and you'll see I've asked, too).

I can't find this dim light slider. I'm pretty sure I've looked everywhere. Can someone guide me?

It appears once you have turned on Low Light:

This quote is massive news from Wil.

We have to remove LDL settings to make UDL work? Can a Roll20 DEV confirm that instruction? Why hasn't this instruction been advertised to the playtesters?

If true, hundreds of Bug Reports and complaints about UDL could come down to simply this one mistake that users could self-correct, or, Roll20 could scrub the LDL settings in the "Convert Lighting" procedure.

No one that I've seen on these forums, to date, has instructed that people testing UDL (on production or dev server) need to remove LDL settings.  If that makes an actual difference, that's absolutely huge, and invalidates much of the playtesting that's been done on UDL by the Roll20 users to-date.

The bulk of user-tests on UDL has been done by LDL users, testing to see if the switch would be acceptable in comparison. Hundreds of hours of volunteer QA testing.

Wil said:

Hi Joseph, I have had this experience too and it seemed to be caused by some tokens still having values in their LDL values. As soon as I removed those values from all tokens on the map, this no longer occured. 

Ah, so it doesn't work for night vision. I thought they were addressing the complaints on night vision.

Brian & Falk --

Re: Map Layer

Streetlights, chandaliers, campfires, torches, The Eye Of Sauron, the fires of hell, are not on the GM Layer and shouldn't be forced to place on the Token Layer. They should be able to be placed on the MAP LAYER just like the buildings, trees, roads, and ground.

Players not having control of those tokens won't save the DM from Selecting all of the Streetlamps and mistakenly moving them, when you're just trying to select the battle participants on the token layer.

Also the GM would be forced to select every single Fire / Chandalier / Lamp and set it to "Is Drawing" mode, one by one, if not you'll have Streetlamp poles with Hit Point bubbles showing. (Token Bubbles & Bars conveniently are automatically hidden if the graphic object is on the Map Layer).

Also all of the Fires & Chandaliers would fall victim to the Z-Order of the Token Layer, whereas Map layer is always behind Tokens.

There are many valid reasons to want Map Layer objects to be able to emit light.

Brian C. said:

Falk said:

But you can always create token that are not in player control, why would you need to put those on the map layer?

That's a good point. That swarm of goblins would generally be on the GM Layer or Token Layer rather than the Map Layer.

Naw, guys. Think more broadly about accommodating different users. We're not all placing Goblins as the light source.

Hmm. Also, it doesn't appear for me at all.

I'm having a bug/ problem where its placing permanent darkness despite explorable darkness being selected. it starts placing explorable then i go to test it and a big chunk of my map is permanently dark.  i've had similar issues with the legacy fog hiding areas while reveal was selected (i would have to select hide and then reselect reveal 

Robert D. said:

Hmm. Also, it doesn't appear for me at all.

Have you activated  Low Light on the token in question? It won't appear until you do, since it's a specifically Low Light setting

Yeah, I have. I'll post a screen shot after the game I'm running. I've tried it with bright light on and at 0.

Wil said:

Hi Joseph, I have had this experience too and it seemed to be caused by some tokens still having values in their LDL values. As soon as I removed those values from all tokens on the map, this no longer occured. I posted about it earlier in this same thread.

Had this 2 weeks ago in a session at a map, all players had this problem at the same time. Two weeks later we picked up another session after removing all the LDL values from all tokens and we had zero issues the whole session.

...

Thanks Wil, going to try this hack at next week's session and see if that works.

Gold said:

Brian & Falk --

Re: Map Layer

Streetlights, chandaliers, campfires, torches, The Eye Of Sauron, the fires of hell, are not on the GM Layer and shouldn't be forced to place on the Token Layer. They should be able to be placed on the MAP LAYER just like the buildings, trees, roads, and ground.

Players not having control of those tokens won't save the DM from Selecting all of the Streetlamps and mistakenly moving them, when you're just trying to select the battle participants on the token layer.

Also the GM would be forced to select every single Fire / Chandalier / Lamp and set it to "Is Drawing" mode, one by one, if not you'll have Streetlamp poles with Hit Point bubbles showing. (Token Bubbles & Bars conveniently are automatically hidden if the graphic object is on the Map Layer).

Also all of the Fires & Chandaliers would fall victim to the Z-Order of the Token Layer, whereas Map layer is always behind Tokens.

There are many valid reasons to want Map Layer objects to be able to emit light.

Brian C. said:

Falk said:

But you can always create token that are not in player control, why would you need to put those on the map layer?

That's a good point. That swarm of goblins would generally be on the GM Layer or Token Layer rather than the Map Layer.

Naw, guys. Think more broadly about accommodating different users. We're not all placing Goblins as the light source.

I think I am being misunderstood. My understanding is that Keith was saying that night vision should be limited in some way when the token is on the map layer. One of the examples was that a mob of goblins with night vision blocked out any ability to see the lighting in the area. My understanding of what Falk was saying was that those NPCs would not normally be on the map layer, to which I agreed. My take is that even if NPCs were to have vision/night vision for some reason, they would be on the GM layer or token layer, and we don't need to restrict night vision on the Map layer because it normally would not come into play in that scenario.

I think we are in agreement, Gold. My take is that tokens should have their full light/vision/night vision capabilities on both the Map and Token layers because that yields the most flexibility in setting up a scene, although I am happy to hear from an alternate point of view.

Joseph B. said:

Wil said:

Hi Joseph, I have had this experience too and it seemed to be caused by some tokens still having values in their LDL values. As soon as I removed those values from all tokens on the map, this no longer occured. I posted about it earlier in this same thread.

Had this 2 weeks ago in a session at a map, all players had this problem at the same time. Two weeks later we picked up another session after removing all the LDL values from all tokens and we had zero issues the whole session.

...

Thanks Wil, going to try this hack at next week's session and see if that works.

I’d also recommend never switching maps during the game if that’s an option for you.  Just have yourself and players start on the one map with lighting you’re using for the session.  Anecdotally that’s helped for me, and switching maps is a key part of my steps to reproduce the issue above - it definitely causes issues.  Obviously it’s a bit problematic depending on what’s going on in the game and not any sort of actual solution.  But if we’ve got to use UDL, I guess do what you have to to not have it drop out in the middle of the game.

Ok, so I'm having trouble with UDL (no surprise really) so I decided to create a new map with no features, just UDL switched on to demonstrate the problem...here goes:

Image 1:

All tokens have all LDL settings turned off!

All tokens are set for UDL as follows...

Image 2:

First token placed on the map in GM view...the tint caused by the nightvision can be seen...

Image 3:

The second token is placed next to the first and the tints are now overlapping...

Image 4:

The third token on the map...getting really hard to see the tokens...

Image 5:

The last token is placed on the map...the tint has now almost totally obscured the first 3 tokens...

In addition, and for some bizarre reason I do not understand, I can see this token clearly, yet it's settings are identical to the first three tokens!

Image 6:

Note that from the players view <CTL-L> everything looks perfect...but as the GM I can't see a damn thing.

To the Roll20 team.

I do not understand why the tint obscures the DM's view of the map? Am I misunderstanding something?

Surely the effect of the tint should be to provide a lighting colour for the player who is controlling the token? Not to tint the GM's view of the map?

This is utterly bizarre and makes the "nightvision" into a "blindness" from the DM's point of view.

Ray said:

Ok, so I'm having trouble with UDL (no surprise really) so I decided to create a new map with no features, just UDL switched on to demonstrate the problem...here goes:

(...)

To the Roll20 team.

I do not understand why the tint obscures the DM's view of the map? Am I misunderstanding something?

Surely the effect of the tint should be to provide a lighting colour for the player who is controlling the token? Not to tint the GM's view of the map?

This is utterly bizarre and makes the "nightvision" into a "blindness" from the DM's point of view.

I posted the same problem earlier without the ilustration. Thank you, Ray.

Got no answers either.

The problem I believe is that in UDL, even without Ctrl+L we, the GMs, see the auta of vision of each token - what did not happen with LDL. When this auras overlaps, they shade the grid, blinding us.

It's a known issue, in the top post (emphasis mine):

NIGHT VISION: There are parts of night vision that still need to be fixed, like night vision tokens overlapping and animated tokens having a ghost like effect on the gm layer. (1) [STATUS: IN PROGRESS]

I just wanted to log an issue I had with UDL, Night Vision, and Party Splitting. This happened on Feb 24.

I was GM and the players were split between two maps. Group A suddenly started having an issue where they were only seeing the grey Explored parts of the map and had no Night Vision. Their tokens were set up correctly, and I tried checking and rechecking, reconnecting, refreshing, but couldn’t get it to to work. As they had already explored the majority of that map, I just turned UDL off for that map so we could carry on.

As soon as I did that, however, Group B on a different map which also had UDL turned on suddenly could see their entire map. UDL still showed as being turned on in the settings for Group B’s map, so I turned it off for them and switched the map and their tokens to Legacy. 

We were mid session so I didn’t have time to take screen shots or anything. Since I’ve started using UDL I’ve ever had a session where multiple players haven’t lost Night Vision during play, and having the whole map get revealed was a bummer.

Drespar said:

It is important to set a target date to hold ourselves accountable for getting UDL to a good place on a transparent timetable. 

“When he reached the New World, Cortez burned his ships. As a result his men were well motivated.”

In this metaphor, UDL is the new world, Cortez is Roll20 Management, his men are the Roll20 developers, and we subscribers are the ships.  

I took you at your word before that UDL was ready for prime time and you burned me bad.  

I don't pay you my subscription fee every month so I can beta test for you.  I refuse to do it anymore.  It's a bad experience for both me and my players when we have to stop our game because someone can't see, or there's confusion because things don't look right, or worst of all, when one player can see everything on the entire map.  

You need to fix all this stuff. It has to work perfectly and seamlessly. 

Then, and only then, can we start talking about killing LDL. 

For any who may not know: the easiest way to disable extensions on chrome is playing Roll20 from an incognito window. File > new incognito window. You’ll have to login again as it also ignores cookies. Good luck. 

Max C. said:

I just wanted to log an issue I had with UDL, Night Vision, and Party Splitting. This happened on Feb 24.

I was GM and the players were split between two maps. Group A suddenly started having an issue where they were only seeing the grey Explored parts of the map and had no Night Vision. Their tokens were set up correctly, and I tried checking and rechecking, reconnecting, refreshing, but couldn’t get it to to work. As they had already explored the majority of that map, I just turned UDL off for that map so we could carry on.

As soon as I did that, however, Group B on a different map which also had UDL turned on suddenly could see their entire map. UDL still showed as being turned on in the settings for Group B’s map, so I turned it off for them and switched the map and their tokens to Legacy. 

We were mid session so I didn’t have time to take screen shots or anything. Since I’ve started using UDL I’ve ever had a session where multiple players haven’t lost Night Vision during play, and having the whole map get revealed was a bummer.

In case the roll20 team is having trouble duplicating this - this behavior is probably related.

Chrome, Incogneto, no plugins

1) Create a new game (no template)

2) Turn on Dynamic Lighting on Start page (page will turn greyish)

3) Create New Page (Untitled)

4) Edit the page settings for "Untitled" (without switching to it)

4a) Turn on Dynamic Lighting

4b) Save Settings

5) Edit the page settings for "Untitled" again (again without switching to it)

5a) Turn off Dynamic Lighting

5b) Save Settings

6) Click anywhere on the canvas (still on the "Start" page).  It'll now turn white for some reason.

Katie Mae said:

Hi everyone! Even though it’s the weekend I wanted to stop in and celebrate: 

• Sean, thanks to your outlined steps I was able to go back and replicate the issue. This is a huge step forward in being able to identify and fix this issue, and the Devs will be psyched to see it on Monday!! 

• Gold: I am unable to confirm the suggestion of removing LDL light values because we have not been able to directly link the correlation. UDL and LDL settings are separate so this should not be necessary. The fact it worked for Wil is something we are still trying to decipher.

• A reminder for everyone: Your first step in troubleshooting UDL issues should be to turn your extensions off. Some of them can completely break Roll20, so just be careful! 

As for the other bug reports in this thread: I will investigate them soon and reach out to you (via Private Message) if I need more information, so look out for that. 

Thanks again, and I hope everyone is having a great weekend!

That's good to hear!  Glad that was helpful!  I submitted a bug report with a game and steps to do that repeatably a month ago - but hadn't bothered to clean extraneous things out of that game one by one to distill the issue down the smallest sequence of steps necessary to make it happen in a clean game until I saw that you were still looking for examples.

Max C. said:

I just wanted to log an issue I had with UDL, Night Vision, and Party Splitting. This happened on Feb 24.

I was GM and the players were split between two maps. Group A suddenly started having an issue where they were only seeing the grey Explored parts of the map and had no Night Vision. Their tokens were set up correctly, and I tried checking and rechecking, reconnecting, refreshing, but couldn’t get it to to work. As they had already explored the majority of that map, I just turned UDL off for that map so we could carry on.

As soon as I did that, however, Group B on a different map which also had UDL turned on suddenly could see their entire map. UDL still showed as being turned on in the settings for Group B’s map, so I turned it off for them and switched the map and their tokens to Legacy. 

We were mid session so I didn’t have time to take screen shots or anything. Since I’ve started using UDL I’ve ever had a session where multiple players haven’t lost Night Vision during play, and having the whole map get revealed was a bummer.

Just as a follow up, I’ve since gone back to test this. Two computers and two accounts, one as GM, one as a player. Both were using Chrome in Incognito with no browser extensions.  I used a game that I use for testing separate from the one I first experienced the issue in. I’m able to replicate the issue every time.

I have two maps with UDL, with the Player Ribbon on one. I split the party and move one player to the second map. I turn off UDL on the first map. The second map is entirely revealed to the player on it, despite UDL still showing as on in the settings.

Though I can't pinpoint precisely when it happened, in the past day or two at least, games with UDL active are utterly unplayable in Chrome for me. Just clicking and dragging the view around the map has a considerable lag, taking upwards of 2-3 seconds to reposition the view and if I let go of the mouse button before it moves, I get a snap back to it's original location.

I can confirm that turning off Dynamic Lighting altogether eliminates the issue completely and I'm not able to replicate it in Firefox, which is smooth as butter. I tried all the de factor troubleshooting to resolve in chrome - latest version check, cleared cache, restarted chrome, restarted computer. No joy. So it's Firefox for now, but chalk up another UDL frustration.

Christopher K said:

Though I can't pinpoint precisely when it happened, in the past day or two at least, games with UDL active are utterly unplayable in Chrome for me. Just clicking and dragging the view around the map has a considerable lag, taking upwards of 2-3 seconds to reposition the view and if I let go of the mouse button before it moves, I get a snap back to it's original location.

I can confirm that turning off Dynamic Lighting altogether eliminates the issue completely and I'm not able to replicate it in Firefox, which is smooth as butter. I tried all the de factor troubleshooting to resolve in chrome - latest version check, cleared cache, restarted chrome, restarted computer. No joy. So it's Firefox for now, but chalk up another UDL frustration.

Beaten to the punch!  I was just about to comment that I find Chrome laggy when I experiment with it, but we have always found Firefox to run really nicely, our only problem right now seems to be the grid with night vision.  Am considering messing about with hard baking it in to the map, though we are only at High Hall in BGDIA and so that would be a lot of maps...

Sooo, small case of boredom, made a transparent grid for this map based on a 70px square in Pshop and added that firstly to map layer and then secondly GM layer, just to see what difference that would make, Roll20 grid turned off.  I realise the GM layer would be no use to players, but wondered whether it would make a difference, which it does.  Opacity of grid in Pshop set to 50% as otherwise it was too dominant. Currently I have followed Keithcurtis' advice and reverted to LDL, but at least I now know I have a workaround of sorts if needed.  This map is entirely UDL and all 3 tokens have night vision active, 60' dimming at 0

MAP LAYER GRID

GM LAYER GRID

This is also completely unacceptable, that LDL settings can interfere with UDL.

Both systems are supposed to be separate (aren't they?).

I don't want to remove LDL settings from tokens, just in case I need to switch back to LDL during a game!

Gold said:

This quote is massive news from Wil.

We have to remove LDL settings to make UDL work? Can a Roll20 DEV confirm that instruction? Why hasn't this instruction been advertised to the playtesters?

If true, hundreds of Bug Reports and complaints about UDL could come down to simply this one mistake that users could self-correct, or, Roll20 could scrub the LDL settings in the "Convert Lighting" procedure.

No one that I've seen on these forums, to date, has instructed that people testing UDL (on production or dev server) need to remove LDL settings.  If that makes an actual difference, that's absolutely huge, and invalidates much of the playtesting that's been done on UDL by the Roll20 users to-date.

The bulk of user-tests on UDL has been done by LDL users, testing to see if the switch would be acceptable in comparison. Hundreds of hours of volunteer QA testing.

Wil said:

Hi Joseph, I have had this experience too and it seemed to be caused by some tokens still having values in their LDL values. As soon as I removed those values from all tokens on the map, this no longer occured. 

This last week I converted my game to UDL using the conversion tool and gave it a try for a session.  

On the whole, it worked better than I expected from this thread.  The map used Explorer Mode, we didn't run into any major issues, and my players liked the new effects.  That said, here are the issues we did run into:

1. A small character token (1/4 of a grid square) typically snaps to the top left of whichever square it's in.  This caused them to repeatedly get stuck inside some walls and be unable to move.
2. When doing Cmd-L on a token to see what it can see, the Light Multiplier setting wasn't being applied.  As GM, I saw them able to see 40' with a torch, but the player with 200% was able to see 80'. 
3. Some walls were bizarrely jagged.
        
4. I ran into the stacking-tinting issue, but it was never so bad that I couldn't see through it.  I can easily see it becoming a problem at some point, though. 

For now, we're sticking with the UDL experiment.

Angelo said:

am i the only one bothered by the selective responses of the roll20 team in this thread and feeling ignored?

is it always been like this with the staff?

-Adam

Just to highlight the answer that was given, Farling,

According to Katie Mae of Roll20 Dev Team, they confirmed that LDL and UDL are separate systems & the settings shouldn't be overlapping. 

Shrug? IDK.

Katie Mae said:

• I am unable to confirm the suggestion of removing LDL light values 
  because we have not been able to directly link the correlation. 
  UDL and LDL settings are separate so this should not be necessary. 
  The fact it worked for Wil is something we are still trying to decipher.

Farling said:

This is also completely unacceptable, that LDL settings can interfere with UDL.

Both systems are supposed to be separate (aren't they?).

I don't want to remove LDL settings from tokens, just in case I need to switch back to LDL during a game!

Gold said:

We have to remove LDL settings to make UDL work? Can a Roll20 DEV confirm that instruction? Why hasn't this instruction been advertised to the playtesters?

Wil said:

x

A couple minor bugs:

- The dynamic lighting layer doesn't show up as blue and highlighted in the menu when you're on it the same way the other three and everything else in the menu does.

- If you toggle "Daylight Mode" on your current page while "Explorer Mode" is enabled, you lose the ability to hide/reveal/reset explorable darkness until you switch pages and back.

Katie Mae said:

Hi everyone! A few things before the weekend:

We have been doing internal testing on the Dev Server this week for an update that optimized Firebase data usage. We expect this update to go live early next week. This is a necessary restructure that won’t impact most users, but may reduce lag for those with the very worst of conditions. 

Also, Wil, in regards to your latest post: I have been working with the QA Team to reproduce these steps and have been unable to do so. What would help us the most here in finding a cause is to provide reproduction steps from start to finish. What we are looking for would be something like:

1. Create a new game using X module/addon
2. Use, or do not use, convert lighting tool
3. Set up a particular page/new page with these lighting settings
4. Set up tokens with these lighting settings
5. Take these actions to cause the issue

A beginning to end breakdown with a fresh game of how to cause the issue to occur it would be extremely valuable.

Have a good weekend, folks! (: 

I was so far unable to reproduce this in a new game, but consistently reproduce the issue in older, fuller games. But with the reproduction as described by Sean G. Page switching and explorer mode seems very much involved in this, at least switching the focus of players and there being a token controlled by players with vision moving around. A refresh seems to fix that entirely. Current tests seem to be that LDL values seem unrelated, apologies for creating that suggestions. If I find any situations where even staying within the same page causes this issue I will let you know.

But looking back also at sessions I had this issue and those I had not, page switching and explorer mode seems the likely culprit.

Small addition to my ealier post, Sean G's reproduction scenario does not work in games in which I did change all legacy LDL values already. So there may be some relation to it I cannot recreate in reproduction. I must add that almost all my UDL games were converted more than a few months ago, as i swapped early to try and get experience in and see all changes come, so maybe that is related as well? 

keithcurtis said:

It's a known issue, in the top post (emphasis mine):

NIGHT VISION: There are parts of night vision that still need to be fixed, like night vision tokens overlapping and animated tokens having a ghost like effect on the gm layer. (1) [STATUS: IN PROGRESS]

Good to know this issue is still present; I'm curious as to what they've actually fixed compared to when I gave this a go around September of last year. It seems nothing's been done since the last time they wanted to sunset LDL.

Speaking of pre-existing issues, here's one I posted about back then in the bug thread that's still present:

Bug: Dim Light from a token causes night vision on other tokens in the radius to be darkened

As the title says when any token with night vision passes through an area of dim light projected by another token the night vision gets darker.

Repro steps:

1. Create a token with Night Vision (example has 60ft radius)

2. Create a token that emits dim light (example emits 20ft of bright, 20ft of dim but same happens on 40ft of dim)

3. Either observe through the Night Vision token's controlling player or via Ctrl + L as a DM

4. Move Night Vision token within dim light radius of other token

5. Observe darkening of vision from the dim light

Here's a pair of visual examples:

Effect is even more noticeable without the Night Vision token set to "dimming"; the night vision token has no tint either.

Also found another bug while showing this one off:

Bug: Viewing a token's vision using Ctrl + L prevents that shortcut being used on another token

So if you select one token, press Ctrl + L to see what it can see, then directly select another token and press ctrl + L the vision doesn't swap to see from the new token. Selecting any other token without deselecting all tokens will prevent the vision from being shown; you will still see the vision of the original token until all tokens are deselected. The other tokens selected after the first token may appear through darkness if not visible to the first token.

As a note, I believe this wasn't the case in September of last year. Back then you could simply swap between tokens without deselecting beforehand; either that or I'm confusing this with the functioning version of this in LDL that does swap the vision when selecting a different token and pressing Ctrl+L.

Repro steps:

1. Select a token, press ctrl + L

2. Select a different token, press ctrl + L

3. Observe vision not changing but token may appear through darkness if not visible to the first token selected.

Visual example:

Enjoy your free QA; you should be paying us for this, not the other way around.

Thanks Drespar for an update. What about the fact that not all UDL-related token attributes are able to be managed by API? There currently does not appear to be a way to enable Dimming or Sharpness. We can set the dimming values through API, but not actually enable.

Drespar said:

Hey Everyone,

Coming back in from the weekend, and have been testing through issues that have been brought up-- I’ll go ahead and respond to them in order on the ones that I have checked and tested:

Ray: Thanks Ray, this has been added to the original post.  As a note, this seems predominantly attributed to the black color tint-- other dark tints seem to have similar effect, but black is the only one that 100% obscures the map. You can work around this a bit by choosing one of the dark gray options which won’t completely blot out everything.

Max C (1, 2) and Sean G (1) : Thank you both for these reports. I was able to reproduce this on my end and it is now in the top level post.

Sean G: Seeing this as well, Sean. Thank you! You will find them in the top level post.

Michael: Thank you for these Michael! They have been added to the original post.

I have gone ahead and updated the top level post with the relevant information and links back to reports in this thread. Thank you again!