These April 15 hotfixes seem very helpful from my perspective. The one regarding light sources was a major nuisance for me, and I'm very pleased to see it fixed. I would like to add another pair of bugs to the list; it may be that these have been captured in one of the queued items in <a href="https://app.roll20.net/forum/permalink/9741240/" rel="nofollow">https://app.roll20.net/forum/permalink/9741240/</a>, but I don't know for sure. I am posting here so that other users may be able to corroborate my observations, and so that people can use this narrative for workarounds when they find bugs in their own games. If Roll20 staff could please shed some light on the matter, I'd be willing to log one or both of these as support tickets. If they are already covered under an existing ticket, I don't see the point. The first bug is definitely a bug; something is broken. The second "bug" is mostly a bug in the sense that it doesn't behave consistently and leads to confusion as a result, and it reveals an avenue for major improvement going forward. First Bug: Let's say that I place a token on the map, set to emit Bright Light to 20 ft. and Dim Light to 20 ft. When a second token is placed on the map, granted vision, and saved, it "sees" this light source appropriately. If this second token is subsequently edited and its Light Multiplier value is changed to a value greater than 100% (let's say it's set to 200%), its vision of the Bright Light updates appropriately, such that it "sees" a Bright Light of radius 40 ft. Its vision of Dim Light does not update appropriately, so it appears as if there is a Bright Light radius, but no Dim Light at all. A page refresh does not remedy this error. But if the light-emitting token is moved even slightly, the Dim Light radius snaps into existence. If a saved token which emits light is dragged from the Journal after the Light Multiplier is edited, its Bright Light and Dim Light render appropriately. I have verified this bug in both Firefox and Chrome, using a dummy player account. This bug does NOT manifest when decreasing Light Modifier, whether from 200% to 100% or from 100% to 50%. It only manifests when Light Multiplier INCREASES. This bug also manifests if two tokens, both controllable by the same player, but with differing Light Multipliers, are dragged onto the map. In this case, the bug again manifests if the second token has a larger Light Multiplier than the first, but not when the first token's multiplier is the larger one. Workaround: The best way to work around this bug is to use a blank map to set up any new player tokens with vision properties that include a Light Multiplier that isn't the standard 100%, and save them in your Journal. Drag them from there into onto the actual map you intend to use. Start with the token(s) with the largest Light Multiplier first. If at all possible, avoid adding any tokens thereafter with a Light Multiplier larger than the largest you are already using. If your map already has lights on it, then after you drag your player tokens onto the map, you will need to slightly move EVERY LIGHT SOURCE. This is a huge hassle if you're using a map with lots of light sources. The fastest way that I have found to do this is to highlight a light-emitting token, use Ctrl-C to copy it, delete the token, and then use Ctrl-V to paste the same token back in the same spot. Once you have reset ALL LIGHTS in this fashion, move the players to your map. Second Bug: Let's suppose that I create three tokens, all with vision. I set Token A to have Light Multiplier 100%, and I set Token B to have Light Multiplier 200%. I also create a Token C, which has Light Multiplier 100%, and has Night Vision to 60 ft.; I set up Token C's Night Vision with a green tint. I am going to use these tokens to represent three different characters, belonging to three different players, Alan, Bertha, and Charlie. I often have my Player Characters navigate tight quarters with bad lighting, so if I set things up so that players can only see through their own tokens' eyes, there's a lot of confusion, it's hard to keep them engaged, etc. So to improve their experience, I decide to make it so that all three tokens are controlled by all three players, because this allows them to see what the other players can see, instead of being strictly constrained by their individual characters' lines of sight. But there also are use cases where the same player might be running two or more characters. Regardless, there are plenty of instances where there isn't a 1-to-1 equivalence, where one player controls one and only one token. So I place these tokens on a map, with a Bright 20/Dim 20 light source like the one discussed in my first bug. Expected behavior is for Token A and Token C to "see" the light source as Bright 20/Dim 20, and Token B to "see" it as Bright 40/Dim 40. Token C, additionally, will "see" things that are only dimly illuminated or that aren't illuminated at all, provided they are in range, and when that happens, a green tint makes it obvious that this has happened. Because all three tokens are controlled by all three players, Roll20 shows the map in a fashion such that if a monster is within the range of Night Vision for Token C and Night Vision would matter, all three players see it that way. Which is good and expected. And if Night Vision doesn't work because Token C doesn't have line of sight to a particular monster, then it fails over to Token B's vision settings, where it might still be visible if something is dimly illuminated to Token B's vision. Again, good and expected. But there is no failover for Token A's vision constraints to show up. Token A and Token C always "see" as if they share Token B's Light Multiplier, even if a player uses Ctrl-L to constrain his or her vision to use Token A only. In essence, Ctrl-L only checks for line of sight when players use it; it does not constrain for illumination. This is an issue if, for example, we want to see whether Token A would actually be able to see a monster, and whether that monster is (from Token A's perspective) in Bright Light, Dim Light, or no light. From the GM's perspective all tokens appear to "see" as if they have Light Multiplier 100%, regardless of whether this is true; Token B looks as if it has the same vision settings as Token A, even using Ctrl-L. This is not as expected, and it's not desirable. If the GM uses Ctrl-L to check visibility through Token A or B, Token C's Night Vision tint disappears. This is actually great, and as expected. Ideally, I think that Ctrl-L (for players and GMs) would cause Light Multiplier and Night Vision to be constrained to use the selected token's settings. This is the mode of operation that I think is intuitive and expected for most users, and it probably also has by far the most utility in gameplay. The way it works right now isn't quite a bug, but it's not totally helpful.