DoorKnocker and UDLWindows windows stopped blocking movement

While setting up dynamic lighting on a map for a new game I discovered that my DoorKnocker created windows weren't blocking movement anymore. After trying to find a solution in the config for the API script, I deleted the script from the game to give UDLWindows a try. The same result. I then logged into my existing game where the DoorKnocker windows have been functioning for several months and discovered that they too were passable. Did something to do with the dynamic lighting fixes in the change log possibly cause this?  I cannot figure it out. Thanks for any help, Spider.

It's very possible. That behavior was always an accident we took advantage of. One way vision walls are on dev right now, and supported windows should hopefully not be far behind.

keithcurtis said: ... and supported windows should hopefully not be far behind. They do tend to last longer than unsupported ones.

Hmm, the changelog for April 5th was several DL related fixes. Possible one of those broke the window hack. I'll look into this when I look into another bug that was just reported.

Ok, I've confirmed this on my end as well. As Keith said, this functionality was taking advantage of an emergent behavior, so there's not much I can do at the moment unfortunately.

Thanks for the replies!  Just glad it wasn't only on my end.  I can live without windows, for now.  *sheds single tear*

I have it on good authority that player-operable doors are in the workshop as well, according to a recent presentation to Marketplace creators.

Hi Spider, I am sorry the APIs you are using broke after updates to Dynamic Lighting's barrier detection. Those APIs leverage bugs in the barrier detention system, which were responsible for several different bad situations with Dynamic Lighting. Things like tokens "peeking" past barriers under certain conditions and "revealing the whole map" to players. Apparently, these same bugs made the APIs mentioned possible. However, after we finish One-Way Dynamic Lighting, Windows is the next dynamic lighting feature on our road map. Thanks!

Can't wait!  Youse guys are doing good work.

Carlos S. said: Hi Spider, I am sorry the APIs you are using broke after updates to Dynamic Lighting's barrier detection. Those APIs leverage bugs in the barrier detention system, which were responsible for several different bad situations with Dynamic Lighting. Things like tokens "peeking" past barriers under certain conditions and "revealing the whole map" to players. Apparently, these same bugs made the APIs mentioned possible. However, after we finish One-Way Dynamic Lighting, Windows is the next dynamic lighting feature on our road map. Thanks! This peeking issue is still happening to me and some other players. I sent a request about it, but is this bug fixing still work in progress or considered as solved ? It's happening to me and other players in my game even not close to a wall, on a 35px grid square map, with one movement or plenty...on firefox or chrome, no extensions installed, no ad blockers.... Really a game stopper for our group Thanks for your attention

Through testing, it appears the the issue occurs when converting a legacy line to one-way. Try using a freshly drawn line. I am consistently able to get the keyhole effect with a conversion, and reliable block with a fresh line.

There's no conversion to one way on my side. I use a map inside a module (DotMM) and the lines are drawn in it from the start. one way walls are only on the dev server for the moment right ? should i go to the walls layer, select all, copy all, erase all, paste it all back ?

One way is active for plus and pro users.

this window change ruined my entire session yesterday ... my players were running around flying away through windows and discovering "secret" areas of the map... damn!

I had the same problem. My player peeked the whole map going near the wall.... This happens on 70 px grid map. The new DL update is a disaster Lionel V. said: Carlos S. said: Hi Spider, I am sorry the APIs you are using broke after updates to Dynamic Lighting's barrier detection. Those APIs leverage bugs in the barrier detention system, which were responsible for several different bad situations with Dynamic Lighting. Things like tokens "peeking" past barriers under certain conditions and "revealing the whole map" to players. Apparently, these same bugs made the APIs mentioned possible. However, after we finish One-Way Dynamic Lighting, Windows is the next dynamic lighting feature on our road map. Thanks! This peeking issue is still happening to me and some other players. I sent a request about it, but is this bug fixing still work in progress or considered as solved ? It's happening to me and other players in my game even not close to a wall, on a 35px grid square map, with one movement or plenty...on firefox or chrome, no extensions installed, no ad blockers.... Really a game stopper for our group Thanks for your attention

The new DL update (one way walls) is  not  a disaster. As was noted many times when Doorknocker was new, "windows" is an exploit of an emergent property of DL (stemming from a bug) as it worked at the time. It was acknowledged that the script could not be depended upon should Roll20 ever fix the bug that allowed such behavior. Instead, Roll20 is working on improving DL so that the functionality that was given by Door Knocker can be extended to Plus users, as well as Pro.

Was it acknowledged that the script could not be depended on? From memory The Aaron had expressed hope that the work on UDLwindow was future proofed. while it may have been an exploit there will be a lot of people that used the UDLwindow script and if that is broken (and I have not been on to check my maps) that will be exceptionally frustrating for many users. they will see that as a disaster

Stavros said: Was it acknowledged that the script could not be depended on? From memory The Aaron had expressed hope that the work on UDLwindow was future proofed. Yep:&nbsp;<a href="https://app.roll20.net/forum/post/9521203/script-udlwindows-dynamic-lighting-paths-that-block-movement-but-not-vision-or-light-warning-updated-dynamic-lighting-only/?pageforid=9521711#post-9521711" rel="nofollow">https://app.roll20.net/forum/post/9521203/script-udlwindows-dynamic-lighting-paths-that-block-movement-but-not-vision-or-light-warning-updated-dynamic-lighting-only/?pageforid=9521711#post-9521711</a> Jarren &nbsp;said: I'm pretty sure this is a bug, not a feature. &nbsp; Hopefully token vision and movement will be separated somehow in future design of dynamic lighting page elements.&nbsp; I would love it if there was a way to set a specific color on the dynamic lighting tab to only block light &amp; vision, another to only block movement, and another to block both.&nbsp; Then getting crazy there could be drawn elements that basically have two lines together to create one-way dynamic lighting. keithcurtis said: I'd call it an emergent feature, since it fills a useful purpose. That doesn't mean it won't be removed if it gets in the way of something else. :) The Aaron &nbsp;said: Yeah, I'd say it's an emergent feature based on the implementation choices in both the collision system (seems to be based on 2d physics against pixel rendered lines) and vision/light (seems to be based on vector line intersections which ignore Cubic Bézier Curves (circles) and Quadratic Bézier Curves (freehand drawings)).&nbsp; My guess is that it will be here to stay, though we may get a more purpose built replacement in the future .&nbsp; Given my druthers, I'd prefer a means to take individual line segments with blocks sight and blocks movement, and which directions those individually affect. I agree that it will be frustrating for players who have been using the UDLWindows or DoorKnocker script for this functionality, but the change will allow for better Dynamic Lighting (such as one-way walls) and eventually a baked-in Windows feature (as Roll20 devs have said that they are working on implementing actual windows into the Dynamic Lighting code).

Jarren said: I agree that it will be frustrating for players who have been using the UDLWindows or DoorKnocker script for this functionality, but the change will allow for better Dynamic Lighting (such as one-way walls) and eventually a baked-in Windows feature (as Roll20 devs have said that they are working on implementing actual windows into the Dynamic Lighting code). There are even some previews for the upcoming door features on the portal!

Yep:&nbsp; <a href="https://app.roll20.net/forum/post/9521203/script-udlwindows-dynamic-lighting-paths-that-block-movement-but-not-vision-or-light-warning-updated-dynamic-lighting-only/?pageforid=9521711#post-9521711" rel="nofollow">https://app.roll20.net/forum/post/9521203/script-udlwindows-dynamic-lighting-paths-that-block-movement-but-not-vision-or-light-warning-updated-dynamic-lighting-only/?pageforid=9521711#post-9521711</a> The Aaron &nbsp;said: Yeah, I'd say it's an emergent feature based on the implementation choices in both the collision system (seems to be based on 2d physics against pixel rendered lines) and vision/light (seems to be based on vector line intersections which ignore Cubic Bézier Curves (circles) and Quadratic Bézier Curves (freehand drawings)).&nbsp; My guess is that it will be here to stay, though we may get a more purpose built replacement in the future .&nbsp; Given my druthers, I'd prefer a means to take individual line segments with blocks sight and blocks movement, and which directions those individually affect. I agree that it will be frustrating for players who have been using the UDLWindows or DoorKnocker script for this functionality, but the change will allow for better Dynamic Lighting (such as one-way walls) and eventually a baked-in Windows feature (as Roll20 devs have said that they are working on implementing actual windows into the Dynamic Lighting code). And in the script thread the posts are around the working of the windows, it’s probable future proofing, the breaking of said script and it working again the collective “we” being tossed around is not correct, and the breaking of a brilliant script is devastating when it has been in use and the eventuality of a windows function is not here [Script] UDLWindows -- Dynamic Lighting Paths that block movement but not vision or light. [WARNING: Updated Dynamic Lighting only]

The reality is that is was an exploit based on broken code. Said over and over in the original UDL Windows script. The alternative is for the code to remain broken and for no new things to be built. Right now, there is a huge leap forward. Pro users have temporarily lost windows. Pro and Plus users have gained one way lighting (which no script provided, and is IMO far more useful) and windows are the very next thing on the development ticket for everyone.) Let me ask: Keeping the script functionality means perpetuating a bug and locking Plus users out of functionality. Abandoning one feature of Doorknocker (doors still work just fine and was the original intent of the script) means the temporary loss of an unsupported feature. How would you solve this? You can't have both.

Thanks for the feature, i'm sad it disable the window for the moment but i feel it's for the best. I hope for bigger DM and a bit for me that the window feature will come quick but in any case, it still feel great to see the tool we use improve !

So it's not just me using it wrong! XD Good to know. The one-way walls are very cool tho, and regular (unlocked) doors still work in Door Knocker, at least for now. Couldn't get locked doors to work, alas.