Wolf Thunderspirit said: Brian C. said: *snip* Vision is a function of a token on a page, not a character sheet. At the time of character sheet creation, a token does not exist. Some sort of automation would need to be added to automatically set values on a token based on attributes on the character sheet when the token is set to represent a character sheet. As far as I know, this functionality does not exist yet outside of the API (Pro feature), and I imagine a script could be set up to listen to various updates and automatically set token values based on attributes on a linked character sheet. Outside of that, you could set up a new suggestion in the suggestion forum, because there is core functionality missing, and that missing functionality is beyond the scope of the character sheet. Is it though? I think what we're talking here is simple. You put an attribute on the sheet "darkvision_range" and "lighted_vision_range". Somewhere on the sheet, you have a box referencing that darkvision, the default being "0" unless a race or class feature grants it. Elsewhere, you have a box on the sheet that says "Torchlight", it's default also being "0" until given a value because the pc uses a torch, etc. The way you do this is simply to add the effects into the token to receive the value, the same as they would HP, Armor Class, or Speed in the bubbles/ bars. Thus making them adjustable on the fly. Torchlight, being a light source, would always trump the vision given by darkvision. Example 1: On Sheet: Darkvision: 60; Torchlight: 0 - sets the token's Legacy DL to 60/30, others do not see light, 360 degrees, 1 multiplier Example 2: On Sheet: Darkvision: 60; Torchlight: 40 - sets the token's Legacy DL to 40/20, others do see light, 360 degrees, 1 multiplier Taking that extra work out of the DM's hands/ setting macros up would be a good suggestion, but it is a sheet topic, as it deals with the sheet (it also deals with the token and Roll20 mechanics - but it starts at the sheet level - without the basis, the token has nothing to receive a value from). Now I'm no stranger to programming. I know that taking a single number and breaking it down to all possibilities would be tedious. And even in that, UDL is beyond my capability of understanding and haven't even tried yet. Even if you took what is currently on the token and added a tab to the sheet for it to be controlled by players instead of the DM - you could still inherit what is necessary for the token's lighting from the sheet rather than the token itself - this way all you need to do is set a default token, and let it interpret what is given on the sheet. IMO, the tokens should be less and less accountable to programming and more just a visual representation on the board. Everything you should need to do should be on the PC/ NPC sheets. By comparison, it would be like saying to your tabletop ... "Hold on a sec. I forgot to setup this mini's vision. It will take me a few minutes and then I have to assign this mini to you Karen." If they didn't look at you like you were crazy, then they are! lol The only thing I would put on the token end is: What the bubble/ bar assignments are (which goes of the defaults in the Game Setup page) Whether any of these bars are visible to others (again, defaults) GM Notes - because we GMs like to be sneaky with certain info A tab of NPC spell slots so that the token - not the sheet that handles multiple NPC tokens - keeps track of it's own spell slot usage. There should be a check box on the token tab to indicate that it should be used, or - if NPC is unique/ named - it can use those on the sheet. On the tab end, we just need to know how many remain, but it should back-end to know how many it started with when the token was dropped on the board from the master sheet. My 2 cents. Chop away at it ... Yes, from the standpoint of the Dynamic Lighting system, vision is a function of the token. My guess is that it will stay that way since the lighting system has to accommodate any game system, not just 5e. If lighting setup data came from the character sheet instead of the token, every character sheet would have to implement the lighting data to take advantage of DL, and games without a character sheet would be unable to use DL. It would also mean that every token linked to a specific character sheet would behave exactly the same way under DL. That might work for PCs in 5e, but other systems might not handle that rigidity as well, and unique environmental situations (such as reduced visibility or blindness) for a certain map page wouldn't be able to be taken into account without changing the character sheet. Again, the DL system could be made that way, but the scope of that change is far beyond the 5e character sheet. From a separation of responsibility standpoint, moving more functionality from tokens to character sheets does not make sense for some of the reasons mentioned above: it causes every sheet maintainer to have to add that functionality, and games would not be able to make use of DL without a character sheet. The tokens are part of the page. DL is part of the page. Any data that affects how a token interacts with the page needs to be on the token because it is the token that interacts with the page and is the object that is the same across game systems. The character sheet handles what is unique to the game system. Vision, in and of itself is not unique to 5e. I don't disagree that a system where the vision setup data would flow from the character sheet to the token is possible, but the functionality needed does not exist at this time outside of the API. Something that automates that process could be added to the 5e Companion script, but adding it in such a way that it does not activate when it is not desired would require some extra configuration. Again, it's not impossible to make such a change to the companion script, but we are talking about saving someone 30 seconds to set up lighting on a token and make it the default token for a character sheet. Considering that in 5e DL should only be set up for PCs, they don't change often, and there is only a few of them in most games, my vote would be for development time being spent elsewhere first. Personally, I would like a programmable area added to tokens that would allow character sheets to add data to the token when a default token is dropped on the page. This would provide the ability to set up spell slot tracking on a per-token basis, but it would first require a new feature outside the scope of the 5e character sheet.