Dynamic Lighting Tips & Tricks

Commander Fayne said: So keep using the old Dynamic Lighting system, because the new one kills established features, *still*. Got it.  I'm not going to use a dummy account to check what my monsters truly see, or to check what my player sees to judge things like cover and line of sight when they ask me to. This is not a fix for my issue, though I appreciate your suggestion. Old LDL never had this strange hard boundary on light sources, and works completely fine with CTRL+L. I am so frustrated with roll20 devs adding new stuff that's broken, has reduced usability, and also lets their established, working stuff fall to disrepair. This is a pretty common theme here.  Using a Dummy Account was a common suggestion before UDL was even a dream. Ctrl-L has limitations. It doesn't provide an accurate experience even under LDL. For instance, the GM layer still displays and Advanced Fog of War can show unexpected results. It sounds like Kraynic has answered the question about feathered edges? Here is the player experience of the settings you have shown. Here is a normal sighted character facing a torch that shines for 2 Bright, 18 Low. Here is the same character but with a 200% multiplier.  It looks slightly different under LDL, but this is to be expected, using two different rendering systems. However, they are functionally identical. LDL Normal LDL with a x2 multiplier   If one had to describe the difference, I would say that UDL is more naturalistic and LDL is more "gameristic". LDL shows the demarcation between bright a dim a little more clearly at the default settings (this can be tweaked in UDL), while UDL is more immersive. But in terms of game play, any differences are minor.

Kraynic said: You have it set up correctly.  Control + L shows the hard edges.  If you add yourself as a controller of the Goblin and rejoin as player, you will see the soft edges.  That is what players will see. What a waste of time to do something the previous system did without having to rejoin as a player. 

Yall really aren't getting it. The old system did something that I want the new system to do. Why the hell does the new system remove functionality? I don't want your dummy account solution. It's not something I've ever had to use before, and I shouldn't have to start now. Old DL system, I would just click a token, CTRL+L and see through its eyes perfectly, feathered edges and everything. Now that the new system breaks that, yall trying to gaslight me in saying the old system was broken too and never worked properly? Are you for real?

I think this has moved beyond the purpose of this thread, which is to share tips and tricks for dynamic lighting.

Keith, you set it up to show properly in your example pics. Did you deselect the character, reselect it and then hit CTLR+L again? I want to know if you're getting the same bug of if it's just me. 

All of those shots were from the player POV, (since players don't have Ctrl-L, of course). Here is a GM screen shot of the light multiplied token. The view is the same no matter how many times I re-select and preview. And I see where the issue with the display is coming from. In the first shot, I get a hard edge with the multiplier token, and yeah, the illumination limit is semi-bugged for Ctrl-L. I agree this is a bug, but it is one circumvented by following the recommended practice of adding the GM as a specific controller to every token that has sight. And yes, it does feel kludgy, and no, you shouldn't have to do that step. However, this practice solves a few other display quirks of UDL, such as washing out of light in some circumstances. With no GM control with GM as a specified controller

Ah, ok. That at least puts my mind to ease that it may have been my selection of API scripts or browser plugins if you're getting the same bug.  Honestly, this feels like the sort of bug that should be fixable. I'm no game dev, but it looks like the part of the engine that handles feathering is somehow disabled by switching off and back onto a token. Is there a place I can report this? It's somewhat niche so there may be a chance the devs don't know about it.  Also, thanks for taking my issue here seriously instead of just blowing me off. I'm sorry I got a bit heated. It just feels incredibly frustrating to have a (pretty critical to VTTs) feature work for years, and then suddenly not work and have some people tell you that it doesn't matter. 

No worries. The best place to post a bug is in the official feedback thread . This is true wherever the devs have started a feedback or bug reporting thread. It may seem like howling into the void, but I assure you the thread is monitored by the dev team and taken seriously. Roll20 has a lot of moving parts, serving over 30 game compendiums beyond D&D 5e, many sheets, audio and video systems, internal technologies such as dynamic lighting, music, and much, much more, that are somehow supposed to work cross platform and all run within the confines of browsers (which they have no developmental control over). As such, work tends to be done in sprints on different parts. It can look like nothing is being done, when in reality a huge amount of work is currently being invested in other parts of the system. Witness the massive compendium upgrade to 5e last week, which took many people many weeks of work to accomplish (and this was only a sub-team). Add onto that the fact that something that seems simple to change might be blocked while waiting for something else to be implemented or upgraded, or is simply impossible given the current state, or just may be of less importance than another developing feature. What I'm saying is, sometimes the wheels of progress move slowly, and it may seem like bug reports are being ignored. They are not. There's just a lot of work, and devs tend to spend more time developing than communicating back to the users, who may be spread out across 3-4 social media platforms. That's one of the reasons why Forum Champs and a few other community leaders do what they can to help. Your voice is heard.

What do you use One-Way Dynamic Lighting for? Can’t really think of a good uses for it (outside PvP scenarios at least). So you can make the ‘false mirrors’ in police interrogation rooms. But you could just add/remove a wall depending on which side the PCs are. A neat but very niche effect. Another thing I tried was high ledges blocking sight. If I draw the line through the middle of hexes on the edge, I get the following effects: Tokens on the ground can partially see tokens standing at the edge, but can’t see anything further in. Tokens standing on the edge are straddling the sight line and thus can see both directions. Tokens standing further out can see through the sigh line, of course. Though if the ledge has any inverse bends, that can create annoying slivers of FoW. But... if people on the ground can’t see people on the second floor, that should work both ways, no? So just a regular sight line would do (besides the annoying slivers of FoW if the line isn’t perfectly straight). Got any neat tricks using One-Way Dynamic Lighting? Normal 0 false false false EN-US X-NONE X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin-top:0cm; mso-para-margin-right:0cm; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0cm; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri",sans-serif; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:EN-US;}

One example is if you make one-way circles over map artwork of columns, trees, etc., you will be able to see the object that is blocking the vision (through the near side of the circle) but sight will still be blocked (from the far side of the circle).

Besides what Kaspar K. noted above, I also use one way dynamic lighting for windows where the PCs don't have normal access to both sides. The one way DL line blocks movement but not vision, so they although they can see through the windows but can't pass through it without breaking or opening it. It keeps PCs from "accidentally" walking through a window and getting an unrestricted view of what's out there. I'm looking forward to Invisible barriers that allow vision to pass both ways but not movement. Doorknocker had this ability but it used a loophole in the DL code to do it and that loophole has since been closed.

Kaspar K. said: Got any neat tricks using One-Way Dynamic Lighting? I have a few interesting uses.  When I set up a map's lighting, I temporarily set the grid size to .1 to allow me to shift-click straight lines and still be within the walls on the map art. I use the Small line size in blue for walls.  Elements that are meant to be moved or altered in some way are in orange. Doors are set up as a Large, box with one-way lighting going in (switching the default direction). The box is drawn with shift-click to be one grid cell wide (at the .1 width). I then use a sighting token on the Dynamic Lighting layer to view the overlap while using Alt+arrow keys to nudge the door over a few pixels into position. This gives a large, solid rectangle that is easy to click but does not block the vision of the door. It even shows up as a small indent in the wall.   I just made a map where the PCs defend a house under siege. Since the majority of time spent looking through a window would be from within the house, I set the one-way walls to work for tokens within the house, allowing them to see outside. The window line can be deleted if the window is smashed or the GM needs to let the players see back inside the house from the outside. My feeling on one-way lighting for "the high ground" is that it needs to be drawn at the edge or outside of the area where the occupiers of the high ground need to stand. For a map with a wall, like castle ramparts or a balcony railing, the line should be drawn along the wall. For a cliff, the line should be drawn along the edge of the high ground's flat territory, allowing the players to see the cliff leading up without showing the flat space on top. Because we don't have layers yet, these lines should be drawn in segments that can be deleted, moved, or shifted to the GM layer without affecting immovable parts of the map. That way player tokens representing flyers or creatures on equivalent high ground can be made to see into the high ground. For columns and other tall objects, I use a square rather than a circle. I don't feel comfortable using curved DL lines.