[Script] DLTool - A Dynamic Lighting Control Panel and Troubleshooter

Hmm. Would a better icon than the gear be more intuitive? My thought was that it would evoke the token "settings" panel. Maybe an exclamation point?   !

This might be more intuitive:

I think that the gear icon is more intuitive, for the reason you stated. The exclamation point make me think of an error message.  Maybe maske the gear icon even larger or a different color?

I considered a different color, but that would give it undue importance. Green is for actionable items. It's just supposed to be a reminder. And I had, just before that last screenshot, enlarged the gear icon as much as I could without increasing the linespacing. The design issue is, to let people know that there is a caveat to using this feature, but not clutter up the interface. It needs to show the user that there is more info here, but not look like a button. An asterisk is something people are used to expect clicking or hovering over in order to get more information, i.e. a footnote. If I were to put a "footnote" asterisk there, giving it the hover text warning, I could also make it green and a button that  deliver the message. That message is repeated anyway, so users would (once they click on one of them) get used to its meaning.

keithcurtis said: I considered a different color, but that would give it undue importance. Green is for actionable items. It's just supposed to be a reminder. And I had, just before that last screenshot, enlarged the gear icon as much as I could without increasing the linespacing. The design issue is, to let people know that there is a caveat to using this feature, but not clutter up the interface. It needs to show the user that there is more info here, but not look like a button. An asterisk is something people are used to expect clicking or hovering over in order to get more information, i.e. a footnote. If I were to put a "footnote" asterisk there, giving it the hover text warning, I could also make it green and a button that  deliver the message. That message is repeated anyway, so users would (once they click on one of them) get used to its meaning. Maybe the  ‘information’ emoji  would convey what you’re looking for?

I have been bitten by emojis in scripts before. Higher-order byte characters can often fail to resolve properly once going through the Roll20 git process. Even if they do make it through, they can display dramatically differently across platforms. I'm going to see what a footnote asterisk looks like. If I go with an info "i" I'll use the Pictos version:  i

Don't forget that UnSanity can tell you many things about if a unicode character will survive the Roll20 sanitation and git-i-fying.

This is what I am leaning toward: You can hover over it, or click it for the message. It's green, indicating a call to action (click me), and looks like a footnote (there's more information here that is immediately relevant):

timmaugh said: Don't forget that UnSanity can tell you many things about if a unicode character will survive the Roll20 sanitation and git-i-fying. I can never remember the name of the script when I need it. :D

Tinted vision and better notification is in the next update. Also, The Aaron gave me some optimization tips that shave about 10% off the execution speed. It will be in the next pull, probably Tuesday.

Very nice job. Thank you for all your hard word. 

Thank you! keithcurtis said: This will be in the next pull:

Awesome script sir; added to the list of vitals for all games. Thank you.

Here is a little preview of some things you will see in the next update (early this coming week). I'll post again when the pull gets merged. Several fun new tools: Page Plus There is now a "Page Plus" option that controls some page settings that are tangential to Dynamic Lighting, such as controlling the grid settings. For example, a common procedure in setting up lighting is to divide the grid into 8ths, so you can snap the lines to just inside the normal intersection, allowing players to see part of the wall. There are now preset buttons for that, as well as buttons for controlling grid color and opacity, page background color, grid type, diagonal measure and more. To access these settings, press the little "+" button next to the page button in the footer. Fit Scale to Map The in-game instructions explain how to use this function: Often a map will have a printed scale that does not correspond to a grid setting. This is typically true of city and overland maps. To set the page scale to correspond to the printed scale, first use the Measurement Tool to measure the printed scale. You may need to hold down the alt/opt key to avoid snapping and get a precise measurement. Remember this number, then press the button below and enter that number into the dialog box. (click for animation) Color Picking: Anywhere you can set color ( token night vision, token light, grid color , or page color ) already has a swatch box. Currently, you can click on the entry for any color definition and enter the new definition manually. With this new version, you can also click on any of the swatches to call up a color picker. The buttons on the color picker match the Roll20 pallet. You can try out multiple options very quickly. Need to find the perfect green for that ghost light? Click-click-click to find the perfect one. Where applicable, you can also control the opacity on this screen. (click for animation)

Thank you so much! :) It's a great tool.

The changes above are now live on One Click.

Player functionality New version should be merged as of today. The newest version allows players to use the diagnostic part of the tool. If I player enters "!dltool" or any of the DLTool commands, they will receive a player-oriented version of the "Why Can't This Token See?" report. It is largely identical to the GM report with two exceptions: None of the controls to turn on light or sight properties will display. That sort of control remains in the hands of the GM. They will however receive an analysis of potential or known problems that would keep their token from seeing the map. If a player and the GM are not on the same page, the player will receive a notice that this is the case. This will help to clear up cases where a player has become split from the party, or there is a communication problem about which tokens are being analyzed. Player view:

Hi Kieth, I tried using the Fit Scale to Map function today and ran into a problem. I followed the instructions (twice) but instead of giving me the distance according to the new scale, the measurement tool displays " NaN ft. / 4.6 sq " as shown below.  The actual numbers that I input at teh prompt were the measured value (22.6), the value on the map (2000) and the units (ft) The value displayed as "page scale" in the DLTools dialog after I did the conversion is  [[(round(($[[0]]/22.6)2000100))/100]] ft keithcurtis said: Fit Scale to Map The in-game instructions explain how to use this function: Often a map will have a printed scale that does not correspond to a grid setting. This is typically true of city and overland maps. To set the page scale to correspond to the printed scale, first use the Measurement Tool to measure the printed scale. You may need to hold down the alt/opt key to avoid snapping and get a precise measurement. Remember this number, then press the button below and enter that number into the dialog box.

Interesting. It works fine on the version I submitted, but not on the script as deployed by OneClick. Something must not be translating properly. Thanks for the heads-up. I will investigate.

Shoot. First, One click isn't pulling the very latest version. That's a mistake I made, and it will be rectified in the next merge. Second, I am not sure what is going on with the measurement routine. That is the same in both versions. In one campaign it works—in another, the exact same code does not. Investigating more.

Sorry for your frustration and hope you discover the solution quickly!  Been there, but as a machine designer not as a coder. It's not holding me back; I was just going to add some "game candy" for my players.

I've discovered the issue. Inline rolls are parsing in my development game, likely due to the action of another script which has an exposed function I was not aware of. I just need to build the function into my own script so it's there natively. I have the code, so it shouldn't be an issue, but it will have to wait for the next merge to implement.

The code has been updated and now parses inline rolls properly.If you want to grab it before the next merge, you can get it here .

Thanks for jumping on this so quickly!

The Aaron gift-wrapped a nice function for processing inline rolls that I was able to drop in with little fuss. As an added bonus, he looked through my development game and discovered the other script that was processing rolls openly and giving me false reports of functionality. So with any luck, I won't have this sort of thing take me by surprise again. All hail the Arcane Scriptomancer!