RPTools
VBL Excluding
Identify the Bug or Feature request
closes #4836
Description of the Change
Unfinished Implementation of VBL Excluding per token. Needs review by someone who knows vision systems better
Possible Drawbacks
Forces frequent regeneration of Vision Areas - performance detriment
Documentation Notes
Adds macro functions to get and set map and token VBL immunity on a token. When set, that token's vision is not effected by that map/token topology.
Release Notes
Added ability for token to ignore specific topology.
This change is 
@kwvanderlinde do you wish to have a go at reviewing this as you have had your head in the code in this area more recently than I have? If you don't have time I can do it.
Yeah I'll have a look. Though I think this could use some discussion at the feature level - it's related to a bunch of other FRs that are better backed by use cases, so I'd like to see how it works together with some of those other ideas.
I'll try to get some of that discussion going soon.
At this point, this is probably the best I can do with this. I think it's usable (or salvageable) as is - aside from the ugly GUI bits.
@kwvanderlinde - you might need to give me some hints on how to mesh my intention with your nice new features.
I think I'll need to take the exclusions as from getTokenVisibleArea() and pass them to zone.prepareNodedTopologies() - but zone.getMasks() does both regular and token topology, and excluding seems to be a single UID to exclude one token only.
As I mentioned in #4836, I don't believe filtering on VBL type is the right way to go. Instead we should be aiming to attach real semantics to vision and vision blocking so that users can control the behaviour based on intent.