Dynamic Lighting Ideas for Multiple Characters

It's a common sci-fi/fantasy trope for one group to see better than others; for example, D&D and its ilk have normal, lowlight, and darkvision, not to mention things like blindsight, tremorsense, etc. Now, with the dynamic lighting system, darkvision is easy enough - give a character a light source only they can see. But it would be nice to expand that idea into being able to have light sources for individual players, rather than just a single/group thing. For example, in my (Pathfinder) party we have a torch-carrying summoner with an eidolon who has darkvision and an elf with lowlight vision. The eidolon has his own light source at 60 ft. The torch-carrier has a light source everyone can see... but I have to keep it at 60 feet, even though most players should only treat it as 40 feet, because if I put it at the shorter distance the elf effectively loses his lowlight. I have to give the whole party lowlight or lose the elf's, and neither appeals. But if the elf player could have a light (from the summoner) at 60 feet that only he could see, and then a separate light at 40 feet that everyone could see, it would work. I don't know how hard this would be from a coding perspective (you already have the ability to give different lights to different people) but from a control perspective this would essentially mean making it so tokens could have several light sources, and every light source had a permissions list of who could see it (like characters and token traits already have).

You could have a light modifier on a token, so for a low light char you might have +20ft, that means he can see 20ft more for all light sources. The way of doing it with the current system is to make the torch its own token set it to 40ft then copy it and set it to 60ft assign one to everyone and the 60ft one to the guys with lowlight, then group them and move them with the players.

Hmm, that's a good idea, though I wonder what happens if you group a token that player A controls with a token that player B controls... can either move the group? Both? I'll have to experiment with this during my next game session.

it doesnt really matter who can move the token if you can trust your group to behave.

Ah, what a sweet dream THAT is. :D Sadly, I have to keep them on a neutral page when they log in and out just to keep them from running tokens in races around the map. The joys of ADHD players...

Derek: If the player who has control of another player's light source cannot play by the 'rules' (dont move it) the solution should be simple: he loses his low-light vision benefits. If he wishes to retain them he will abide by this rule. :) - Gauss

totally agree with gauss a VTT can only do so much, some time you just have to drop that d20 of dragons on them if they refuse to play ball.

Moving grouped tokens turns off lighting I believe.

No tested and working in a live campaign just this second.

totally agree with gauss a VTT can only do so much, some time you just have to drop that d20 of dragons on them if they refuse to play ball. I've had GM's threaten me with Bugs Bunny and the Road Runner. MUCH scarier. ;)

MapTool did lighting, vision, and LOS right with the individual views and various types of lights, vision types, and such. Roll20 would do well to take the best of MapTool lighting/vision and refine it.

I'm not sure roll20 really needs or wants that level of complexity.

Well, there may be a workaround... but if the answer is, "trust your players" then what is the point of even having permissions in the first place? For that matter, why bother to have GM only sections, and just tell my players not to metagame or I'll drop dragons on them? As for roll20 needing it... strictly speaking, *any* kind of dynamic lighting is already outside what a tabletop game can do. The fact that it was added shows someone with the power to make it happen wanted it, in spite of it "adding complexity." Adding permissions to light sources may be easy or hard, I don't know, but the idea that "roll20 doesn't want it" isn't a good argument against it.

Just cause an option is available doesn't mean people need to use it. It is just that... an option. There are plenty of things in Roll20 that you don't need or can't do at a table, but they're in anyway. Lighting, vision, and LOS is essential for worm types of competitive games. They're also a very awesome feature that helps create a certain ambiance you can't replicate at the game table. Simple lighting and vision settings actually help streamline combat and exploration since it removes the need to ask if you can see something of not.

My point is we have working "Simple lighting and vision settings", I can see that we need some sort of modifier that we can add to tokens to make low light work without having to make multiple tokens, but LOS is not system agnostic and as such IMO shouldn't be part of Roll20 as one of there goals is simplicity and system agnosticism (is that the right word?). Jonathan I suggest you go listen to the latest podcast the stuff they talk about in that has relevance to the sort of thing you want implemented.

Line of sight is pretty damn system agnostic. The biggest reason for adding LOS is to hide tokens with visible light sources not controlled by the player when they are Blocked by a wall or in another room. That's the type of line of sight I'm talking about. Not the line of effect/sight that determines how much cover or concealment something has. That is done by eyeballing it.

I see what you mean, its interesting but again I think that should be left to be dealt with by the possible API in the future as regardless it wont be system agnostic in edge cases as different systems determine if something can be seen or not in some odd ways. For instance depending on the layout 4e d&d can sometimes have a token that a typical computer game type LOS would consider to be in LOS but isn't because of the way you measure. My point is it is possible we would end up with the same problem that we had with measuring diagonals, a simple feature gets added then it slowly come out that it doesn't work right for X system and then the devs are almost forced to fix it to keep system agnosticism thus creating unforeseen feature creep.

Token vision management in regards to Fog of War and Dynamic Lighting is far too complex for only being in the API.

I'm not going to argue about an assumed complexity of doing something with an API that doesn't exist yet. I merely gave my suggestion for a solution to what i perceive to be the only real flaw with adding LOS. Do you have a better way that doesn't involve Roll20 have yet more drop downs to pick what system you are using? Don't you think it would be far better for such things to be done by giving access to useful hooks, events and functions that would let the community implement what ever sort of LOS system (or anything else for that mater) they needed for their game?

You don't need system specific lighting or vision or LOS. We already have a basic form of LOS with dynamic lighting. Tokens without lights won't show up until a light source illuminates them. What I want is for tokens not controlled by a player to not be visible if blocked by dynamic lighting. The npc token shouldn't be visible even though they have a light source. The column should block sight to that token.

In regards to line of sight, I have to agree with Jonathan. Though I would call if Line of light, to differentiate it from LOS. what I believe he is trying to suggest is allowing multiple sources of light to be visible to all players - a torch is, after all, still a torch, and everyone can generally see it - but illuminate only the sections of light that are visible to the characters icon from the its placements, not in relation to the source of the light. this would allow for many more options when creating maps and plannig adventures. imagine - and this applies to ANY system - a dark corridor, the only light source being your torch. now imagine moving forward and as you approach a corner, a light source shining from around a corner. you KNOW something is creating a light source that is visible to your character, but you cant see the source itself. Right now that is very difficult to do (fog of war is limited in its current form and essentially replaced by dynamic lighting at least in most of my maps) as you put down a light source, mark is as visible, and suddenly the players can SEE WHAT IS IN THE ROOM! some sort of change in code or addition of code to only allow a character to see lit areas of the map in direct line of sight from his character (according to the lighting layer blocks) is not in any way system specific. It is simply a method of controlling how much information is available to the players without having to rely on constant and gametime consuming micro-management of the fog of war. It would be a wonderful addition to the still in development dynamic lighting, and I hope to see it implemented someday, but I dont know what the Devs have planned, though I hope whatever they implement next is at least as useful as this. after all, the system as is is still far superior than relying on the fog of war alone, and I imagine they have to put what they can in as their time allows. If I could code at all, I would happily join them in their efforts, just so I could use the benefits in my own game. Sadly, I have real skill at coding, so I will content myself to what I hope are helpful suggestions and debates like this one, because after all, debate only fuels the creative process.

I understand perfectly what is being said (I don't get why you need to keep explaining when I have never said anything to indicate I don't understand what you are asking), all I have ever said is the way you work out LOS is not system agnostic, although the problem only arises in edge cases it will still arise.

LOS only matters per system to figure out how much cover a target has or not. There absolutely does not need to be any drop down menus for how much of a token is visible or not. I just want to be able to put light sources that everyone can see without revealing the whole map.

actually you measure from different points on the model/token depending on what system you use, in some it doesn't say but some like 4e have a particular corner you measure to and from. This is for LOS not just cover. See image for what I mean, in some systems the bug bear would not be in LOS but in 4e he would be.

If you turn on dynamic lighting and use the blocking tool, the two tokens wouldn't see each other by default.

I just untick the show light to players box.

Which defeats purpose of having dynamic lighting. Light is visible to everyone unless you're blind. If a goblin has a torch and is around the corner, you should see the light even if you can't see the token.

I am not sure what anyone is gaining from this discussion anymore.

I agree this would be a pretty cool feature. Not sure how tough the coding would be, but given what a great job the Devs have done so far, I imagine they've done a fair bit of tough coding already. As for remaining agnostic regarding LOS around corners, I can't imagine a situation where the method of determining it is going to make or break a session. Pick the most logical/commonly used/easiest to code, and get back to the game. We'll play with whatever we can get.

For the record - I just tried out the idea of grouping a "light" token with the torch-bearing character. Still don't know who can move the group - my game is later tonight. Results were... less than spectacular. First, unless you turn off snap-to-grid, tokens don't retain relative positioning in groups, so unless the light is full-token size (thus allowing my players to see the giant light bulb I used rather than a tiny speck) the light source will always be coming from one corner of the square instead of the center. Not a huge problem - I made it full size and hid it behind the grouped character. But even then, it did funny things. Like shifting the apparent light source while the character was in the process of being dragged, rather than waiting for placement. Sometimes this shift would put it behind walls, illuminating an area meant to be always dark; sometimes in a hallway that hadn't been explored yet. At this point, I'm just going to leave a giant light bulb visible and tell the player controlling it to move it to the spot where the torch-bearer goes.

Derek, that is odd behavior. I have not seen the same thing. The token should remain with the group in it's relative positioning. Note: if you are using the shift key there is a shift key bug that causes a grouped token to be sent god knows where (usually down and to the right). How I use grouped light tokens: 1) In the art library I search for 'torch' and select a torch that I move to the tabletop. The torch should be the same size as the player token (although this admitedly creates centered light rather than light from a corner). 2) I set it to the desired light radius and set it to be controlled by the person(s) that have low-light vision. 3) I then send the torch to back so it will be behind the players token (though this can be done after they are grouped). 4) I then move the token to the players token and group them. If I want to access one token alone I can hold down the Alt key to do so while clicking on the group. This will select one grouped object (the top object). Alternately, if you wish to keep the torch in one square you can make the torch a small size, group it, and whenever you move the token hold down the alt key before placing the token in the new location. - Gauss Edit: I tested it and I see what you are talking about now. When a 0.5 by 0.5 size token is grouped with a 1 by 1 size token and the 0.5 by 0.5 token is partially not in the square it may jump to the adjacent square. Solutions: 1) Hold down Alt when moving the group (not when selecting the group), it will not snap to grid. 2) Make the torch full size. 3) Move the torch separately. Finally, Dynamic Lighting is still a relatively new feature.

May i suggest instead of using a torch token just duplicate the token you want to have the light that way it can be hidden very easy.

Second problem - can't access attributes of a grouped token.

Hold alt and double click. I think that should get the attributes of the top token.

I don't know how hard this would be from a coding perspective (you already have the ability to give different lights to different people) but from a control perspective this would essentially mean making it so tokens could have several light sources, and every light source had a permissions list of who could see it (like characters and token traits already have). I'd give my vote for multiple light sources per token (as with auras). It might also be an easier solution coding wise - which might make it available sooner - than creating modifiers for a single light source? I'd love three light sources (i.e for reduced/normal/improved range) per token with an additional check box for active/inactive. This would allow for ample customisation. (great workaround ideas though - thanks for that ^^)