Researching on another tack, I came upon to need to filter the results of ‘Get movable area’ call in SLG movement.
In SLG movement, you can direct it to get a path, or get a movable area. I needed a movable area. Getting a movable area also has a ‘cost’ function. The issue I initially faced was that when you assign
slg.BLOCKING as cost value, you are blocking that line of search.
The image above shows a case situation (though this is depicting the problem solved). The yellow circle is trying to find a movable area beyond the LOS of the blue circle. The green circles denote valid movable areas, which, again, are the result of having the issue solved. The tiles with LOS is depicted as the squares with the white outlines. Originally, I had put a blocking cost to tiles that are LOS’d, and the result was that I wasn’t getting any green circles.
When the ‘Get movable area’ cost function is run, it seems to spread out to tiles that are movable. However, if a blocking cost was assigned, then it can never branch out past that, unless it finds another route. In the image, the yellow circle is completely surrounded by LOS’d tiles, and therefore, even though tile # 427 and tile # 475 might be out of LOS, the ‘Get movable area’ function can’t get past those tiles that have been blocked.
To make this work, it had to be a 2-step process. First, make a simple ‘Get movable area’ cost function in which
impass=1 is blocked, but everything else is nominal.
Next, filter the result of the cost function further.
So now, in the filter function (‘remove LOS tiles’), the resulting tiles gathered by SLG needs to be appended back to a list (before it’s actually passed into the InstanceGroup).
All tiles that are not appended to this filter result will not be put in the InstanceGroup. So this is a matter of the explicit inclusion of tiles to this result.
In the above image, those tiles that are not LOS’d, are put into the InstanceGroup.