New Dynamic Lighting UI?

I have been building some maps with Dynamic Lighting this week, and just today something changed in the UI.  Specifically, when I pick the drawing tool a little menu comes up with a wall icon and a color icon - see below.  The dropdown for the "Wall" gives the option for Wall or One Way.  And the color dropdown lets me pick the usual line-size (tiny to extra large).  And to select color, click on the color swatch and it brings up a new selector with a much wider range of colors (yay! - not that DL colors really matter). Is this a preview of additional changes?  Where do I look for announcements on how this works and what to do with it?  

Seems to be a new feature. From the roll20 facebook: <a href="https://fb.watch/cocFunEHXf/" rel="nofollow">https://fb.watch/cocFunEHXf/</a>

It was announced as live on the Dev forum, so not everyone saw it. Roll20's new policy is to announce all updates on Friday, even if they happened earlier in the week. This was the announcement from when it was on the Dev Server: Corey J. &nbsp;said: Hey everyone, We’re excited to roll out a new feature for Dynamic Lighting: One-Way Dynamic Lighting Barriers. Now when on the Dynamic Lighting Layer GM’s can select a new type of line to act as a Barrier known as “One Way”. When a line or shape is drawn when this input is selected triangles will appear near the line letting you know which way light and vision will bypass the barrier.&nbsp; You can also toggle the direction using the button in the submenu.&nbsp; For those looking to add barriers as they know them now, they are still the default option and are listed as “Walls” in the submenu. All your currently applied lines and maps will default to this automatically.&nbsp; There are two tiny bugs currently, but both can easily be worked around: keithcurtis &nbsp;said: I have discovered two minor issues that are fixable with a workaround, but might warrant dev attention: Converting an existing (legacy) wall to one way status and re-sizing the thickness results in the "keyhole" problem. Tokens that hug a wall can see a wedge of vision beyond them. Walls generated from scratch do not have this issue. When converting existing maps (unless this is fixed) it would be best to re-draw light blockers that need one-way vision. The color picker is gone for the DL layer. The DL layer now uses a plain continuous rgb picker. This will require either manually putting in the rgb values to retain consistency (which may affect some scripts such as Door Knocker), or selecting an existing wall so the eye dropper is set to that color for the next thing it draws. Lines drawn on other layers do not have this issue.

can we disable this? i like the idea but now i have to know the exact color pallet for making doors, walls, and windows for other API *thumbs down

also my API for windows isnt working now because of it&nbsp; -_-

Dunge Onmaster said: also my API for windows isnt working now because of it&nbsp; -_- <a href="https://app.roll20.net/forum/permalink/10799136/" rel="nofollow">https://app.roll20.net/forum/permalink/10799136/</a>

keithcurtis &nbsp;said: The new DL update (one way walls) is&nbsp; not &nbsp;a disaster. As was noted many times when Doorknocker was new, "windows" is an exploit of an emergent property of DL (stemming from a bug) as it worked at the time. It was acknowledged that the script could not be depended upon should Roll20 ever fix the bug that allowed such behavior. Instead, Roll20 is working on improving DL so that the functionality that was given by Door Knocker can be extended to Plus users, as well as Pro. When Scott wrote this, he (and I) predicted there would be people upset when the bug was fixed. From the very beginning, the windows function was in jeopardy, and he let people know it. Windows were something we discovered to be possible , based on some faulty behavior. True windows are next on the dev list, and player-operated doors are on the horizon. All of these things are good because a huge number of Plus level users will be able to use them.

Personally.... i would rather have my windows than the color pallet and the one way lighting, which was already an option with API. The color pallet is making it 10x harder for DMs

I agree that the color pallet is something that is a downgrade, and have posted as much. I disagree that the one-way lighting was possible with Door Knocker's exploit. It was an either/or. One way opens a lot of great possibilities, like an object that blocks sight, but still allows you to see the object, such as a pillar or tree. And the window feature lost with the exploit are coming up next. And doors. All of which will eb available to many more users than previously.

there was an API for one way lighting already

How do we simulate glass now? the "upgrade" only lets you see one way

Dunge Onmaster &nbsp;said: there was an API for one way lighting already That was not the same thing at all. That particular script was an attempt to create walls that would remove themselves under very specific circumstances to simulate getting close to an edge. Nothing one-way about it. And even if it were, it doesn't do anything for Plus users. Dunge Onmaster said: How do we simulate glass now? the "upgrade" only lets you see one way Not sure why upgrade is in scare quotes. It is an upgrade. Plus users can use it. It is long-requested. And the Door Knocker script did not allow for one-way walls. As for windows, before the exploit occurred there was no way to do windows. The way that Door Knocker used was based on faulty code that broke other things, like the ability for tokens to pass through certain parts of a circle. I know that doesn't help you do windows at this moment, but if you don't see the improvement this makes for users who are not Pro, the ability to do things you couldn't do before, the closing of a bug, over the temporary loss of an accidental feature, I don't think I can make my case any other way.

I just assumed this would be an update for UDL only, but it seems to be available for LDL as well.

Brett said: I just assumed this would be an update for UDL only, but it seems to be available for LDL as well. You can define the lines, but unless you're doing something I'm not, the one-way functionality isn't there.

keithcurtis said: Brett said: I just assumed this would be an update for UDL only, but it seems to be available for LDL as well. You can define the lines, but unless you're doing something I'm not, the one-way functionality isn't there. Oh, I haven't tried it out yet, I just noticed that the menu option was available in my LDL game. Oh well...

I think it's because LDL is no longer being developed. The interface doesn't technically break anything, it just doesn't do anything different. And it couldn't. this sort of enhancement is precisely why LDL was abandoned.

keithcurtis said: I think it's because LDL is no longer being developed. The interface doesn't technically break anything, it just doesn't do anything different. And it couldn't. this sort of enhancement is precisely why LDL was abandoned. Yeah, I know, I've just been reluctant to switch to UDL. One of my players has an older computer and another has rural internet. I tried using animated weather graphics one time and the lag it created for them was terrible. I'd love to take advantage of the bells and whistles that UDL offers, but my players are more important to me.

I have four players, two of whom have older computers. I do a lot of prep work on a Chromebook. Neither has ever affected dynamic lighting. Animation however, is a non-ideal implementation on Roll20, to put it kindly. For UDL, refrain from tinted light or giving NPCs sight. Make yourself a specified controller on NPCs and you have avoided nearly every weakness of the system. LDL also has its problems. Advanced Fog of War is kludgy and reveals more than it should. I never used it. Characters cannot carry a torch and have dark vision. Windows and one-way walls are impossible. UDL has issues, but LDL has its own. YMM, of course, V.

keithcurtis said: For UDL, refrain from tinted light or giving NPCs sight. Make yourself a specified controller on NPCs and you have avoided nearly every weakness of the system. I never used Fog of War at all, so that's never been a problem. I should probably create a test campaign with UDL, have my players log into it, and just see if it works alright for them. I do sometimes need an NPC to have vision, because what they can see will affect what they do. But your suggestion seems like an easy enough work-around. It's a shame about animated graphics, though... having falling and blowing snow while DMing the classic AD&amp;D Frost Giant module looked awesome in theory.

With Pro you can use a Token-mod macro to quickly toggle vision on or off for any given token. Fog of War is not the same thing as Advanced Fog of War. (One of the best things about moving to UDL was retiring that explanation—bad name choice) The former is a free user level method of manually masking areas of the VTT. The second was similar to Explorer mode, but IMO, vastly inferior, revealing entire grid squares at a time instead of following token vision lines. To do the initial testing, my suggestion would be to use a&nbsp; Dummy Account , regardless of which system you use. I have mixed feelings about animated graphics. I recognize the whiz-bang appeal, but I started playing D&amp;D back when the most advanced video game was the Atari VCS. I like to simulate tabletop play, and not video games. But I absolutely understand that some folks would love to have them, and the current implementation is "not ideal".

Dunge Onmaster said: Personally.... i would rather have my windows than the color pallet and the one way lighting, which was already an option with API. The color pallet is making it 10x harder for DMs I'm not totally clear whether it matters how I pick my colors.&nbsp; Players don't see them, so they don't affect their experience.&nbsp; And I use just a few colors for wall vs door, so it's easy to find and remove.&nbsp; (The eventual "door" capability will be much appreciated.)&nbsp;&nbsp; Is there something I am missing with colors that would be more useful?&nbsp;&nbsp; The color-picker would be GREAT to have with the map / token layer to provide more nuanced drawings.&nbsp; (But then, I am not an artist when it comes to these things.)&nbsp; It's still nice to have a stable of standard colors, like we have now.&nbsp;&nbsp;

The difference is consistency. For example, all Roll20-produced modules use the exact same color across all products: a specific blue for walls, a specific orange for doors. Besides making it easy to recognize (which is important for many reasons, such as accessibility, clarity and proofing), it serves a second, more critical purpose. Many API scripts that deal with walls need to be able to recognize what is a wall and what is a door. They do this by color definition recognition. The API doesn't understand orange and orange-ish red. It wants the color "#ff9900". There are other reasons that the API needs specific color definitions, but that's the number one. You already have the full spectrum of colors with the existing picker, by being able to input that rgb definition. The new color picker allows you to input a color but it's actually less robust, not allowing you to input an alpha value (two more digits). You can still do this were it matters (map, gm, and token layer), but if the new color picker were to spread we would lose the ability to put down semi-transparent shapes, useful for irregular "auras".