[#4698] Auto-sync actor senses to prototype token vision

[Sayshal]

Updates the prototype token's sight range, vision mode, and detection modes when an actor's senses change. Works for direct edits on the actor sheet, senses inherited from species items, and Active Effects that modify sense ranges.

CONFIG.DND5E.senses has been expanded from string labels to objects so each sense can declare a detectionMode, whether it grantsSight, and a visionMode:

DND5E.senses = {
  blindsight: { label: "DND5E.SenseBlindsight", detectionMode: "blindsight" },
  darkvision: { label: "DND5E.SenseDarkvision", grantsSight: true, visionMode: "darkvision" },
  tremorsense: { label: "DND5E.SenseTremorsense", detectionMode: "feelTremor" },
  truesight: { label: "DND5E.SenseTruesight", detectionMode: "seeAll", grantsSight: true, visionMode: "darkvision" }
};

Modules can extend this config to add custom senses with their own detection/vision mode mappings.

Vision range is the max of all senses with grantsSight. Senses without it only add detection modes. So an actor with darkvision 10, truesight 30, and tremorsense 60 gets a sight range of 30 with feelTremor and seeAll detection modes.

The prototype token is kept in sync through CRUD handlers (preCreateSenses, preUpdateSenses on AttributesFields, and _syncTokenSenses on Actor5e called from descendant hooks). Placed tokens on the canvas also get overrides applied during TokenDocument5e.prepareBaseData, before V14 AE token changes run.

A few notes:

• Controlled by a new senseVisionSync world setting (default true)
• Compendium imports and explicit prototype token edits are left alone
• Non-sense detection modes the user has configured manually are preserved
• Includes a migration for existing actors (systemVersion < 6.0.0)

Closes #4698

[thatlonelybugbear]

Is there a need for this to be gated behind a setting?

[Sayshal]

Is there a need for this to be gated behind a setting?

I think so, it's automation that writes to tokens, and the system already gates similar behavior behind toggles (disableConcentration, disableAdvancements, movementAutomation). It also gates the migration, so existing worlds with manually configured token vision don't get overwritten on upgrade.

The DND5E.senses config restructuring itself isn't gated — the detectionMode, grantsSight, visionMode metadata is always available. The setting only controls whether the system acts on it (writing to prototype tokens and applying runtime overrides on placed tokens).

Defaults to true so it just works unless someone explicitly turns it off. That said, I'm not strongly attached to it, so if the consensus is it's unnecessary overhead I'm fine to drop it.

[roth-michael]

A high-level consideration: We might want to, instead of manually setting values on the token during base data prep, leverage Actor#tokenActiveEffectChanges for handling the downstream effects. If we did that, I don't think we'd need to touch the Token code at all.

[Sayshal]

A high-level consideration: We might want to, instead of manually setting values on the token during base data prep, leverage Actor#tokenActiveEffectChanges for handling the downstream effects. If we did that, I don't think we'd need to touch the Token code at all.

I tried following through with this in the PR. I got things functioning, but two things came up that I want to ask about before updating the PR.

First, the synthetic changes need a stand-in effect. ActiveEffect5e.applyChange opens with change = change.effect._applyChangeShim(change), so a change I push into tokenActiveEffectChanges with no .effect throws on scene load. I worked around it with this:

const effect = { _applyChangeShim: change => change};
changes.push({ effect, key: "sight.range", value: sight.range, type: "upgrade", priority: 0 });

This works, but its clearly abusing _applyChangeShim.

Second, and the bigger one: even with that, the change can't move what actually governs darkvision. _prepareDetectionModes runs in prepareBaseData and seeds basicSight.range from sight.range, but my injection lands in the final phase, after that. So I can set the sight.range field, but basicSight is already baked from the source value. The only reason vision looked correct in testing is that the prototype-token write had set sight.range on the source early enough for basicSight to pick it up. The tokenActiveEffectChanges pass changed nothing.

Am I missing a cleaner way to give these changes a real effect, or to get the range set before detection-mode prep?
Otherwise I think the prototype write is the way to go here.