Add proper support for various sense to tokens

[arbron]

A broad roadmap for improving how senses defined on the Actor5e are applied to tokens and rendered on the canvas. The goal is to have each of the different sense defined in 5e rendering in a way that makes the most sense.

Actor5e Changes

Add "Blind" checkbox to actor's senses configuration that sets their default vision to nothing by linking up with the upcoming attribute on tokens (see foundrynet/foundryvtt#5484). Other senses such as Blindsight and Tremorsense would allow "Blind" actors to still see.

TokenDocument5e Changes

Add the various forms of vision to the TokenDocument in addition to the existing Bright and Dim vision values. These values should be updated dynamically when changes are made to a linked actor.

Vision Effects

Possible rendering changes for each of the different types of vision.

Blindsight

Display everything as if in bright light regardless of normal lighting level. If the actor is "Blind" or the area is in darkness, render this radius in greyscale. Possibly apply other effects to the vision to distinguish it from darkvision.

Darkvision

The most commonly addressed sense (see #30 & #738), this would mean rendering anything in dim light as if it were bright light, and anything in darkness as if it were dim light without color. Core support is required for fast grayscale support, but it seems we are coming close.

Devil's Sight

Same as darkvision, but sees through darkness created by inverse lights.

Tremorsense

Doesn't reveal any of the map, but does reveal all tokens (on the ground, not ethereal) within its radius regardless of walls.

Truesight

See through areas of darkness and see any invisible tokens within range. Not sure if there are any other effects possible for this.

[arbron]

Originally in GitLab by @xdy

Might be worth excluding creatures with elevation > 0 and creatures with the Etherealness feature from being revealed by Tremorsense. See https://www.dndbeyond.com/sources/basic-rules/monsters#Tremorsense

[Dumbhuman]

Darkvision

The most commonly addressed sense (see #30 & #738), this would mean rendering anything in dim light within Darkvision range as if it were bright light, and anything in darkness within Darkvision range as if it were dim light without color.

I added the emphasized bits, because current behavior for Darkvision is already rendering all Dim Light as Bright Light without that important range restriction. There is a module called Adequate Vision which adds the range restriction, so hopefully it's easy enough to implement as the system's default behavior without any modules.

Darkvision works very well for me in Foundry VTT v9.280 running DnD5e v1.6.3 and using Perfect Vision v3.9.15 (plus its dependency LibWrapper v1.12.8.0) as the only modules enabled:

I'd love for it to work just as well in v10, but currently in Foundry VTT v10.288 running DnD5e v2.0.3 things look like this:

Using just the Adequate Vision module in v10 gets closer to what can be achieved in v9, because it adds the range restriction on turning Dim Light into Bright Light, but unfortunately it doesn't yet address the issue of Darkness incorrectly becoming Bright Light instead of Dim Light:

Incidentally, Roll20 correctly handles Darkness within Darkvision range becoming Dim Light, Dim Light within Darkvision range becoming Bright Light, but obviously they're missing the conversion to grayscale feature (and a ton of additional lighting features that Foundry has):

Getting rules-accurate Darkvision handling in DnD5e for Foundry v10 without any modules involved (so that it'll be properly supported for future core/system version updates) would be absolutely fantastic and something worthy of advertising all over the place. I'm sure it's not an easy task, but just wanted to say that I absolutely appreciate any and all effort that goes towards implementing it.

[caewok]

Regarding tremor sense: A slightly more nuanced version might look something like this:

• The token with tremor sense must be on or below the "ground" for the sense to work. In default Foundry v10, I would interpret elevation = 0 as "the ground." You probably should anticipate modules (Levels, Elevated Vision) will redefine ground at any given point.
• To "see" another token requires that the other token also be at or below the "ground." For default Foundry v10, this is again elevation = 0.
• More long-term, I would consider giving tokens a property that can be set when they are on the ground, under the ground, or above the ground (flying). This property should be distinct from, but related to, elevation. You can approximate "on the ground" by checking if the token elevation is equal to the scene elevation at a given point, but this can get complicated. For example, a token may be on a bridge. If the "bridge" is a tile, then in theory a token is "on the bridge" if the token elevation equals the tile elevation. But being "under the bridge" doesn't place the token underground. And of course, someone will want to cast "fly" and have their token float 1 inch above the ground, making their token basically still at elevation = 0 but not be detectable by tremor sense.
• Some will probably debate whether different "ground" types transmit tremor sense. For example, creature with tremor sense on the ground outside a house --- can it "see" a token on the roof of the house? I would definitely ignore this complication and tell those people to go write a module!

[Dumbhuman]

I wanted to make some Tremorsense suggestions too.

I think the Flying condition, which already exists in DnD5e, should be used to make a token both unable to use and unable to be detected by Tremorsense. Elevation of tokens should really only play a role in determining whether any potential target is in range.

The assumption that anything above 0 feet elevation is not touching the ground assumes no map will ever have different elevations of ground area: no stairs to defend, no cliffs to climb, no ridges riddled with archers, no high ground to hold, etc. Page 84 of the Dungeon Master's Guide has a section titled Fun Combat Encounters which recommends among its bullet points "terrain features that provide a change of elevation", highlighting the importance that Tremorsense supports elevation changes for the ground itself.

Consider this scenario where Stabby is climbing a wall to join his beloved Stabigail atop a plateau. See Invisibility properly allows him to detect both of the Invisible Duergar Mind Masters:

However it seems incorrect that Stabigail's Tremorsense doesn't detect the Mind Master 15' up, consdering he's actually much closer to her. This is a byproduct of Tremorsense ignoring tokens above 0 elevation:

Another reason that elevation shouldn't be the deciding factor for Tremorsense is that there are plenty of cases where a Token can be considered at 0 elevation while still not touching the ground. Think Animated Swords, Beholders, Will-o-Wisps, Pixies, etc.

I don't think a Grounded condition is needed, if only because I think it's safe enough to treat being grounded as the default state (just as walking is the default movement speed) with Flying used to make exceptions as needed. Maybe adding an Ungrounded condition for non-flying tokens unconnected to the ground (climbing/hanging on a free-floating structure) might cover all bases. That would allow the framework for certain modules to make certain areas like a rope bridge or maybe a roof automatically apply the Ungrounded condition to any non-Flying token entering that space.

Ideally, I think it would be nice if Tremorsense detection worked similar to See Invisibility, producing its effect on all viable tokens within range on top of other vision detection modes. Offhand I can't think of any creatures having Tremorsense without also having Darkvision and basic sight. In my example scenario there are Elementals burrowing underground, but Tremorsense currently doesn't pick up on their outlines unless I disable Basic Sight detection (at which point anything not detected by Tremorsense disappears):

On a related note, just as I dislike elevations above 0 being treated as in the air, I also dislike elevations below 0 being treated as buried and unseen underground. If I wanted a 30 foot deep sinkhole to open on the above map, I should be able to show token elevations within that sinkhole without losing sight of them. Note that if I put -30 elevation on the Earth Elemental it will disappear from the map just as the Xorn at -10 feet has. This makes it very difficult to show the progress of tokens climbing out of the hole:

I'd much prefer that visibility change to ignore elevation completely and instead be tied to a Burrowing condition. Ideally the Burrowing condition would also hide elevation numbers from anyone who doesn't have Tremorsense, just as the Invisible condition hides that info from anyone who doesn't have See Invisibility. Consider the below example where I've turned off Stabby's See Invisibility so he can't see the Duergar tokens to the south nor their elevation info, but still somehow sees exactly how deep the unseen Elementals to the north are:

[Dumbhuman]

Just wanted to make an update to Darkvision since I just tested it in v11.300 with DnD5e v2.2.1:

I'm very excited to see that Darkvision is now correctly rendering Darkness as Dim Light (rather than Bright Light)! Now all that remains is to make sure that Dim Light renders as Bright Light only within Darkvision's range. The module Adequate Vision was able to impose such a range in v10, but the author has stated it is not being updated for v11 (and really the only feature needed from it is the range restriction). Hopefully the DnD5e system can implement the Darkvision range restriction itself so that rules-accurate Darkvision won't require any modules at all.

[LukasPrism]

Can we just roll Eber's Vision 5E into dnd5e and call it a day?

[arbron]

Can we just roll Eber's Vision 5E into dnd5e and call it a day?

I believe that is the point of Eber's 10 vision-related PRs, but they are being held up by some changes needed from V12.

[LukasPrism]

Ah interesting, thanks. If this is the issue it's awaiting then it looks like we might be waiting a bit longer, these changes have been booted from v12 https://github.com/foundryvtt/foundryvtt/issues/9783. At least we have V5E to tide us over.