Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account

Magical Darkness script via Dynamic Lighting Layer

1593905707

Edited 1603976945
David M.
Pro
API Scripter
My first API script(!), inspired by a "Stupid Trick" proposed by Avi: <a href="https://app.roll20.net/forum/post/5899495/stupid-roll20-tricks-and-some-clever-ones/?pageforid=8900893#post-8900893" rel="nofollow">https://app.roll20.net/forum/post/5899495/stupid-roll20-tricks-and-some-clever-ones/?pageforid=8900893#post-8900893</a> Avi represents magical darkness by drawing a grid within a circle on the DL layer. It blocks line of sight from both the exterior and the interior, without covering tokens on the object layer like a big black circle token does. Players controlling characters within the darkness will see only their token.&nbsp; Cool idea, Avi! Rather than drawing this manually every time, I thought this would be a good use of API scripting to automate. Also, it sounded like a fun first javascript project ever for me :) To use: Create a dummy character whose token has the desired size and image of the darkness generated (e.g. 20ft radius black circle) Add an Ability macro to call the new !dldark script and set as a token action Ideally used in conjunction with Token-mod to send the darkness token to the map layer (e.g.&nbsp;!token-mod --set layer|map) &nbsp;Added this functionality directly to !dldark So, drag it out and click a token action to summon your darkness. The script draws an approximated circle (stole a portion from TheAaron's !dlcircle script) on the DL layer of the same diameter as the token's width, and using the token's position. Additionally, interior gridlines are drawn within the circle to block LoS for those within the darkness. The entire drawing can be moved easily as one object by the GM if there is a need. Using Token-mod to then move &nbsp;Moving the darkness token to the map layer allows character tokens within the darkness to be seen clearly by the DM, while the player will only see his/her token. Note that if Restrict Movement is ON, then the GM will have to move character tokens in/out/within the darkness, but them's the breaks! EDIT v0.2 -- &nbsp;updates include (1) optional "buffer" that brings the radius of the darkness in a bit so players can see the edge of the effect causing the darkness, (2) interior grid optional, (3) automatically aligns the DL grid with the actual map grid (based on page settings), (4) supports gridless maps, and (5) gives the option whether or not to move the source token to the map layer. Code moved to github here: <a href="https://github.com/djmoorehead/roll20-api-scripts/tree/master/DL%20Darkness" rel="nofollow">https://github.com/djmoorehead/roll20-api-scripts/tree/master/DL%20Darkness</a> Some screenshots. First, the darkness token is dragged to the map (20ft radius, in this case) After the !dldark script is run, in both GM and player view modes. (Note, token-mod was used in the screenshots, too, so the darkness token is now on the map layer): &nbsp;Edited: token is now moved to map layer as part of !dldark script (optional). Here is the player view when inside of the darkness Syntax: !dldark &lt; buffer &gt; &lt; makeGrid &gt; &lt; sendToMapLayer &gt; " buffer " &lt; # &gt; Optional. Default = 0 reduce the radius of the darkness by this many pixels. allows the source of the darkness to be seen at the outer border of the darkness. " makeGrid " &lt; true / false &gt; Optional. Default = true draw a grid inside of the darkness circle. the grid will be aligned with the map grid based on page settings " SendToMapLayer " &lt; true / false &gt; Optional. Default = true send the source token to the map layer after creating the DL path? if true, will send to map layer and perform a z-order "ToFront" if false, will keep on token layer and perform a z-order "ToBack" Example syntax: !dldark !dldark 15 true !dldark ?{buffer radius?|15} true false Animated gif (click to play). Cloudkill in a tavern. What could go wrong? This example also uses my Spawn script to create the source token prior to creating the darkness effect.
1593913536
The Aaron
Roll20 Production Team
API Scripter
Nice! &nbsp;I'm without a computer right now (needed a battery replacement) but I'm looking forward to poking at this later in the week! &nbsp;Nice job!
Thus looks great.&nbsp; &nbsp;Question though, if the DL is set to restrict movement will thus still work?&nbsp; It seems like that would disallow tokens moving into and through the circle.&nbsp;
1593941541
David M.
Pro
API Scripter
Yeah, easy to miss in the [admittedly overly long] original description that restrict movement will require the GM to move the tokens into, out of, or within the darkness. I haven't actually used this in game yet, so not sure how organic it feels in actual gameplay. I suppose the player would just give the GM a direction they want to move (possibly through the measure tool arrow) and GM would handle it until they were out. Also note that if somebody is rocking 5E's Devil's Sight invocation or some kind of Truesight, this technique will also cause problems and a different method should be used.&nbsp; I just liked the idea of Avi's "clever trick" and thought it would be a fun learning project for me and potentially useful for anyone who wanted to implement his trick :)
1593943854
David M.
Pro
API Scripter
UPDATE:&nbsp; I added the "move token to map layer" functionality to the end of the script to eliminate dependence on token-mod, via: tok.set("layer", "map"); Edited original post.
1593960265
The Aaron
Roll20 Production Team
API Scripter
If you're feeling sassy, you could add a proxy token for each player token in the radius. Make it transparent (just grab the URL from Bump) and don't give it sight (Tokens with no sight aren't blocked by Restrict Movement), move it to the front, and move their real token wherever the proxy token is moved. Look at Bump or TokenCondition for examples. &nbsp;
1593965339
David M.
Pro
API Scripter
Interesting idea. Would that cause problems with any macros that rely on @{target|token_id} or&nbsp;@{selected|token_id}, since the Slave token is on top? Seems like I would have to handle those target or selection events and "transfer" to the underlying Master token? Like finding tokens that share the same position as the target but lack a predefined descriptor (e.g. "_proxy") in their names or something?
1593977218
The Aaron
Roll20 Production Team
API Scripter
You can set the proxy to be just like the real token, save that it has no sight or light settings. That will let macros work correctly.&nbsp;
1594040348
David M.
Pro
API Scripter
Ah, got it. Slick. For my group, I don't think the GM-only movement is *too* cumbersome, but I agree it would result in a more organic solution. Thanks again for your help earlier when I was just trying to get this off the ground!
1594043092
The Aaron
Roll20 Production Team
API Scripter
No problem! &nbsp;I think it's a nice "where to I go next" problem to work on. There are lots of problems I've solved with follower token like that. Bump, TokenCondition, TurnMarker, Mark, Facing, Torch, etc. It's a nice tool for the tool belt. =D
1594146464
David M.
Pro
API Scripter
Blarg, giant sad face. I spent several hours deciphering and integrating invisible proxy tokens to the script for tokens within the darkness radius (obv stealing heavily from the Bump script), but as soon as I removed sight from the proxy token, toFront no longer has any effect. The proxy token stays behind the Master token. Did some forum searching and it looks like there were some changes related to AFoW (around a year ago?) that is throwing a wrench into the works. Apparently, if two tokens are controlled by the same owner and one has sight while the other doesn't, the sighted token stays in front, regardless of commands to the contrary. Unless there is some other inventive workaround or I am misunderstanding the situation, looks like this approach is DOA. On the bright side, at least it was an otherwise educational exercise! <a href="https://app.roll20.net/forum/post/7892438/token-order-move-to-back-slash-front" rel="nofollow">https://app.roll20.net/forum/post/7892438/token-order-move-to-back-slash-front</a>
1594150281
The Aaron
Roll20 Production Team
API Scripter
Hmm. You could oversize the proxy token (say 1.5 times larger) and give it an aura only the controller can see, then it can be selected around the edge of the real token.&nbsp;
1594150316
The Aaron
Roll20 Production Team
API Scripter
That really is the most annoying anti-feature that was never requested....
1594155734
David M.
Pro
API Scripter
The Aaron said: That really is the most annoying anti-feature that was never requested.... Haha, yeah right? Oversizing could work, but kinda annoying if there are multiple adjacent tokens. Also, I was thinking: the proxy token concept would also allow players to walk thru "real" walls, too. So, I suppose I would then have to start checking prev and current location against the line segments of all DL paths other than "darkness" paths to see if the token has tried to move across one, and move them back if true. Getting pretty complicated for such a niche script...
1594155960
The Aaron
Roll20 Production Team
API Scripter
Yeah, that's fair.&nbsp;
To be honest if I was running magical darkness, I would have the player ping where they wanted to go. Then roll some dice to see how well they navigate in the darkness and then move them. That way it is easily possible to get lost in the darkness
1594209675
David M.
Pro
API Scripter
Good tip, Slowglass! GM could also ping outside of the darkness in the general area where the players are hearing sound to give them some clues. Yeah, the proxy token concept was going to be an optional argument passed to the script depending on how the GM wanted to run it. It was a great idea by Aaron, but it seems more trouble than it is worth now considering the recent changes to the behavior for multiple tokens with the same owner.&nbsp;
Nice, vast improvement on my original design, super cool!
1599496183

Edited 1603138656
David M.
Pro
API Scripter
Version Update 0.2 Updates include: optional "buffer" that reduces the radius of the darkness (relative to source token) by a user-configurable amount so players can see the edge of the effect causing the darkness interior grid now optional automatically aligns the DL grid with the actual map grid (based on page settings) supports gridless maps gives the option whether or not to move the source token to the map layer. Animated gif (click to play). Cloudkill in a tavern. What could go wrong? This example also uses my&nbsp; Spawn &nbsp;script to create the source token prior to creating the darkness effect. Script syntax used in above example: For spawning of the cloudkill token (requires the SpawnDefaultToken script, linked above): !Spawn {{ --name| GenericSpellAoE --offset| 4,-2 --size| 4.1,4.1 --side| 11 --order | toFront --expand| 20,50 }} For creating the heavily obscured area (using DLDark script) !dldark ?{buffer radius?|15} true false
Does this work with UDL?
1600265588
David M.
Pro
API Scripter
I haven't tried it, but It should be no problem since all it is really doing is drawing lines on the dynamic lighting layer, and not dealing with how those lines are handled by the VTT :)
This script is awesome! I'd advise against using it with UDL, though. When I tested it out on a page then turned on UDL on that page, a weird effect happened where another page's map got superimposed, then I couldn't load into that page or switch to another page until I went into the settings and turned off UDL on that page, and even then the problem didn't resolve until the next day. I've been using UDL on all my other pages, and never had that big of an issue. The grid/polygon didn't even get made on the lighting layer. But I turned on LDL on that page then used the script, and it all worked out fine.
1601074938

Edited 1601075495
David M.
Pro
API Scripter
Sorry to hear that, Persephone. I'll check it out this weekend, but honestly don't know what else I could do since it is a pretty simple script that literally just draws lines. I'll probably hold off spending too much time looking into the matter until things get stable with UDL. They've been throwing out hotfixes all the time lately. I may post to the ever-expanding UDL bug thread if I can replicate the problem on my PC. Thanks for the feedback! EDIT - ok just checked really quick with UDL and everything worked very smoothly for me. Tried basic command as well as all the options. Running Chrome on Windows with no extensions. I have absolutely no idea what happened in your case. I guess with all things UDL, YMMV :/
I assumed it was an issue on UDL's part, didn't mean to imply there was an issue with your script! Just that UDL may interact with it poorly. I haven't done further testing in my main game but will test in a separate game both with and without this script. It's entirely possible UDL has a bug with just being activated on a page under certain conditions.
1601151107
Andreas J.
Forum Champion
Sheet Author
Translator
Persephone said: I assumed it was an issue on UDL's part, didn't mean to imply there was an issue with your script! Yeah UDL isn't finished yet so it's sensible to assume any new issue with the script due to UDL changing behaviour from some bug-fix or other recent change.
1603195104
David M.
Pro
API Scripter
Interesting turn of events. Apparently the next UDL update will have some sort of Magical Darkness capability, described briefly here . Sounds like it could be nice, when they get all the kinks ironed out of UDL in 2024 or whenever. Hopefully they will provide API access to this function so it could be automated. My bet is TheAaron will have something within 10min of the access being granted, lol!
Yea that guys a wizard/jedi multi class&nbsp;