[Script] UDLPasswall -- Walls that block sight but not movement!

UDLPasswall v0.1.0 UDLPasswall converts path objects to paths that block vision but don't block movement. This requires twice the space of the opening to make the full distance open. The excess space is spread to either side by default, but can be grouped on one side or the other, or can only require part of the space if you don't mind having some movement blocking in the middle. Commands !to-passwall [--help | --ends | --lower | --top-left | --upper | --bottom-right | --middle] --help &nbsp;-- Displays this help --ends &nbsp;-- Places the excess wall on either side of the opening evenly.&nbsp; Default --lower &nbsp;-- Places the excess wall toward the top-left (lower coordinate numbers) --top-left &nbsp;-- the same as&nbsp; --lower &nbsp;but possibly easier to remember --upper &nbsp;-- Places the excess wall toward the bottom-right (higher coordinate numbers) --bottom-right &nbsp;-- the same as&nbsp; --upper &nbsp;but possibly easier to remember --middle &nbsp;-- Place the vision blocking space in the middle of the replaced line. However, there will be a section in the middle that blocks movement. Usage Select path objects on the Dynamic Lighting Layer and run the&nbsp; !to-passwall &nbsp;command. Each of the path objects will get moved to the GM Layer and a version will be created that only blocks vision and light, but will not block movement. You can adjust the way the DL version is created by rerunning commands on the GM Layer line. If you delete the GM Layer line, it will remove the DL lines. This works with single segment poly lines, but not boxes or circles. Note: &nbsp;the&nbsp; --lower / --top-left &nbsp;and&nbsp; --upper / --bottom-right &nbsp;arguments check the vertical axis first, so a line drawn from bottom-left to top-right will get the excess applied to the bottom left when using the&nbsp; --upper &nbsp;argument. The way this works is with a very short line with a very broad stroke.&nbsp; That means the sight blocking is equal on both sides of the real line.&nbsp; The various arguments are all about where that line goes (and how many there are). Some examples: 1) --ends (default behavior)&nbsp; This places lines on either end of the opening which are large enough to have their sight blocking meet in the middle: This gives a fully open area with no collisions in the opening.&nbsp; However, the sight blocking area extends half the width to either side of the opening. (green and red in the image)&nbsp; This would be a problem if you were on a corner. 2) --lower or --top-left &nbsp; This places a single line at the lower coordinate of the line, meaning it will be at the topmost, then leftmost end: This gives a fully open area with no collisions in the opening.&nbsp; However, the sight blocking area extends the full width above the opening. (green in the image)&nbsp; This would allow you to place it next to a corner on the bottom. 3)&nbsp; --upper &nbsp;or&nbsp; --bottom-right &nbsp; This places a single line at the upper coordinate of the line, meaning it will be at the bottommost, then rightmost end: This gives a fully open area with no collisions in the opening.&nbsp; However, the sight blocking area extends the full width above the opening. (red in the image)&nbsp; This would allow you to place it next to a corner on the top. 4)&nbsp; --middle &nbsp;&nbsp;This places a single line in the middle of the opening: Since the line is in the middle, the sight blocking extends no further than the opening.&nbsp; The line in the middle is technically a collision point, but if the wall is thin enough that it's significantly smaller than the bounding box of the token being moved, it will pass right over it without issue. Note: Right now, this will only work on a single segment line, meaning it has a starting point and an ending point.&nbsp;&nbsp; The converted line is moved to the GM Layer.&nbsp; You can adjust what method was used for a line by selecting it on the GM Layer and running a different one.&nbsp; When the GM Layer line is removed, the DL Layer sight blocking lines are also removed. Git:&nbsp; <a href="https://github.com/shdwjk/Roll20API/blob/master/UDLPasswall/UDLPasswall.js" rel="nofollow">https://github.com/shdwjk/Roll20API/blob/master/UDLPasswall/UDLPasswall.js</a> Support my work on If you use my scripts, want to contribute, and have the spare bucks to do so , go right ahead. However, please don't feel like you must contribute just to use them! I'd much rather have happy Roll20 users armed with my scripts than people not using them out of some sense of shame. Use them and be happy, completely guilt-free! Disclaimer: This Patreon campaign is not affiliated with Roll20; as such, contributions are voluntary and Roll20 cannot provide support or refunds for contributions.

(Updates)

(Other)

Nice!

This is in the 1-click scripts now!

Also, it appears the UDL updates from yesterday prevent the exploit we were using from working.&nbsp; That's unexpected and unfortunate. =( Actually, this is still working!!!&nbsp; &nbsp;UDLWindows appears to be broken still, but we'll see.

The Aaron said: Also, it appears the UDL updates from yesterday prevent the exploit we were using from working.&nbsp; That's unexpected and unfortunate. =( Hopefully there will be another way to accomplish these wall tricks (official or otherwise).

Wasn't there an&nbsp;Alanis Morissette song about that? Doesn't bode well for my 10,000 spoons script.

HAHAHAHA.&nbsp; Actually, it looks like this one is still working, it's just UDLWindows that's not working now.

Woot, UDLWindows and UDLPasswall are both working again now!!&nbsp;&nbsp;

Out of curiosity is it possible to make walls that only block the line of sight in one direction? For use in cliffs or towers, where you want to block sight from the bottom to the top but not from the top to the bottom. Or is that simply too complicated for it in its current form?

Not currently.&nbsp;