Dynamic Lighting Sightlines blocked by non-existant walls

So I've had this issue with a few of my maps where I've created fairly simple sets of walls and torches on the lighting layer, and when using a test character to move around the map I'm seeing invisible walls that are seemingly blocking line of sight for players. I'm not sure where these are originating but it would be helpful to see if others have solutions for this issue. ^ Here I have my lighting layer open showing the walls I've used around the map to block line of sight, as well as torches placed around where light sources will be. ^ This second image is what my player sees when in the game, there is a diagonal \ invisible wall that is blocking their sightline to the right. ^ This third image shows what the player sees when they move past the invisible wall to the right, now their sight is blocked from where they came. I'm interested to know whether this is a common glitch, and whether this is an easy work around. Kind Regards, Diplonio :)

It looks like you used freehand to draw your walls. That is most likely the cause. Replace all your freehand walls with polygon/line walls.  If you would prefer not to do all of that, you can copy your page, then remove the freehand walls one by one until you find the particular freehand wall causing the issue. Then on the original replace that particular wall.

I can't tell for sure from your map, but it looks like the walls are drawn freehand. This creates a burden for dynamic lighting, and has some unpredictable effects. If you replace the lighting lines with the line segment tool, instead of freehand curves, does this still happen? In my experience, I can have pretty complicated walls made up of line segments without triggering problems. As a pro user, you may also want to get the DLEllipseDrawer mod for the API. It's available on the one-click menu. It works to turn ellipses drawn on the DL layer into polygons which suppresses some problems. It won't help with converting freehand drawings however.

It looks like you are using the freehand tool to draw dynamic lighting lines.  You should try redrawing it using the tool that lets you draw segments instead.  Freehand basically creates a very large number of wall/points to calculate light from, and eventually webgl (or whatever) just gives up.  Basically, never use the free hand tool for dynamic lighting lines and this sort of thing should go away. Edit:  Well, we all piled on, didn't we....  :p

You might want to check out my PathEditor script. It has a "Simplify" command that reduces the number of points in freehand drawings. It might save you from having to re-draw everything with the polygon tool. You can always use the script to tweak a few of the vertices after simplification if they lose too much resolution around tight corners.  See example of Simplify in use here . This reminds me: I need to add this script to the one-click repo...

Thanks guys! I had a feeling that might be the case, I'll stick to lines from now on! Cheers! Diplonio

Ugh I was having this same issue. Having to use the polygon tool for stuff like caves that aren't straight lines sounds like a chore and a half. I'm very sad this was the cause. 

Lucas S. said: Ugh I was having this same issue. Having to use the polygon tool for stuff like caves that aren't straight lines sounds like a chore and a half. I'm very sad this was the cause.  I never found that to be the case. Just keep laying down points while doing the line.  Click (left click), move mouse, click, move mouse, click, move mouse, click...etc until the line is drawn, then right click to end the line. It goes pretty quickly. 

You can also end a line by pressing the escape key, so segments don't have to connect into complete polygons.

Valerie M. said: You can also end a line by pressing the escape key, so segments don't have to connect into complete polygons. Right click does the same thing. :)

As a matter of practice, the current advice from the developers (and the technique used by the conversion team) is to use several shorter segments rather than one long continuous line, as well. This is more efficient for the rendering engine, and makes edits much easier. It's faster to replace one short line than to redraw an entire perimeter.

That's interesting, Keith. Are you saying that given the same number of vertices and cumulative length, having a larger number of path objects is more efficient for the LoS / ray tracing algorithm? Since I use ParhEditor a lot to tweak complex paths (more segments per path object), it's acrtually easier for me to have fewer path objects. Hmm, if you confirm the interpretation above, that's something I'll have to keep in mind in the future if I start to have lag issues.

Here's an example, using the map above. There is no hard and fast rule for the most efficient line length, it ultimately works out to a matter of preference, with the only guide being fewer points to calculate = better performance. Again, this is what I have been taught through my work as a conversion contractor, and the advice of the development team. In my rework of the lighting above, i have done the cavern outline in several segments rather than one continuous path. This has fewer points by a couple of orders of magnitude than a freehand line would produce, and has the additional benefit of letting me redraw a small segment rather than the whole line if I need to edit. Not as big a deal on a cavern map, but on a "dungeon" map, this could be invaluable in fixing a discovered light leak or misplaced edge. I have used a different color for each segment, for clarity. This is not recommended for an actual map.

As an alternative, here is a method I sometimes use for caves. This works best if you are not using lines to hinder movement. One line (red) separates the major areas, and then smaller lines (green) just control sightlines on corners. Depending on the map, this can be quicker to draw, and is extremely editable. It also works best for maps where the background is black.

David M. said: That's interesting, Keith. Are you saying that given the same number of vertices and cumulative length, having a larger number of path objects is more efficient for the LoS / ray tracing algorithm? To answer this more directly, given the same number of vertices and cumulative length, I am not certain if there is any performance difference. If you are using a script to break apart lines that need editing, then you might not need to worry about number of paths . But without that (which would be true for all plus users, and probably the majority of Pro users), then using the same number of points, but already separated into more paths makes a difference in terms of editability.

Ah amazing thanks Keith, I really like the use of those lines to cut the sightlines on corners I think I will start doing that too!