#Vision Mode Changes
1 messages · Page 1 of 1 (latest)
This thread is available for those impacted by these changes to get assistance or have questions about them answered
Vision Mode Changes
So, it's a good thing I never got into working on my v10 full rewrite and instead opted to do types then.
I'll skip the vision stuff for types and chew on other stuff for now then.
What will this add that a client setting to disable visual effects from vision modes wouldn't? Having it on a per-token basis?
Assuming you're using the full vision modes featureset (and not just using this as a selective way to disable specific things), then it vastly expands the potential for vision modes by allowing you to configure the visual and sensory data separately.
So for example, if I'm a wizard with darkvision and I cast See Invisibility, I would no longer lose my darkvision while I have See Invisibility active.
Conversely, if I'm a wizard without darkvision, my See Invisibility spell will now work without granting the ability to let me see in the dark.
ok, neat
From a system perspective, it means you don't need to declare new vision modes for as many permutations of senses (EG: Darkvision+See Invisibility, Darkvision+Precise Scent, etc) because you can toggle them separately
It should also make it easier for temporary effects that modify your senses (again, See Invisibility being the most obvious example from the core presets) to be applied to a character without completely wiping their sight preferences (for instance, if they have a certain filter or contrast level that they like)
God, when I have time to be in the polygon mines, I've going to have a blast making a night vision mode.
i think we have one out of the gate.
Oh, well, there goes some of my fun.
I'll just have to find something else to make then.
current default light amplification mode:
Yea, gut want's to play with that to add a bit of static since it's too clean for atheistic reasons.
oh man yeah, you totally could, i'm pretty sure @azure rose exposed pixi filters a while ago
I thought about this a little bit. Wouldn't most vision modes end up being both as Sight and Detection modes? Wouldn't it make more sense to make no distinction between Sight and Detection, and instead come up with a way to merge vision modes and their attributes?
I'm suspecting the reason for the split is that some systems have conditional "do you see them or not" statuses. A token may be invisible, but you might have see invisibility. A token may be underground, but you might have tremor sense. A successful stealth check should make them invisible to certain people, except those that can use an alternative sense, or have a high enough perception dc
you might have a combination of ways to see and ways to detect, like darkvision + tremorsense
darkvision and tremorsense would each entail pairs of sight and detection modes, though
monochrome (sight) + see tokens in dark (detection) on one hand, bizarro-underground-effect (sight) + see <0 elevation tokens (detection) on the other
which really puts us back at square one, with the exception that darkvision detection can now have the bizarro-underground-effect
Will this allow for multiple simultaneous detection modes?
For example, having detect invisibility up and tremorsense, to see the tokens of both invisible creatures and those underground. Just an example, though. I'm guessing more combinations and options would be possible.
...so basically, I'm asking whether what Supe said will be possible now.
will the new mode split allow for setting or changing if certain objects are visible or not? tokens, tiles, and so on?
(passive perception high enough to see a secret tile, and so on)
maybe even choosing whether a tile is wholly visible or only where the fog engulfs it out of the vision radius?
(making my life simpler 😄 for supporting isometric module in v10)
Will there be a UI option to have detection mode automatically follow the sight mode settings (which will likely be the case for 95% of the time)?
If there is, will this be enabled by default?
I agreed with the rationale to post this announcement and thread because I think it’s important to let folks know that we are going to extend our V10 timelines and make a change to the new vision modes feature - admittedly later in the process that we normally would like.
Answers to most of the questions posted here, however, will likely have to wait until after we have prototyped the change and understand exactly what it gets us.
If we had more time here, I would have preferred to avoid a sponsored discussion about it until after we have a working (and testable) proof of concept.
At a conceptual level, we have currently a problem that mutually exclusive vision modes work poorly when it comes to detection rules. It’s a fair concession that the visual style of how you see the world is only rendered in one way at a time - but not being able to access a mode of detecting that some other token is present was a limitation that was not acceptable to some users and members of our team.
While I cannot say for certain what exactly will be possible with the change we intend, a key goal for it is to allow the detection logic of “can I perceive X thing” to be separate from how we render the appearance of the scene. This will allow for multiple detection modes to be concurrently active so that, for example, you can see through walls at 10ft, see invisibility at 30ft, and see movement at 60ft. Each special mode of detection might be called out visually in some way to denote that it is non-normal.
I thought of this some more. I think some of the problems with merging of vision modes is contributed by the fact that normal eye sight isn't a vision mode itself and blindness is.
Blindness isn't a real vision mode, it's something that affects one or multiple vision modes. The better solution for blindness, I think, would be adding the organ property to vision modes, which is either EYES, EARS, NOSE, or SPECIAL. While the token is Blinded the ranges of all vision modes that are ear-based are forced to zero (disabled); same with Deafened. So if Blindness is no longer a vision mode, it makes merging easier I think.
It's not quite possible to model eye sight with the vision modes at the moment. The range is of course infinite, but it shouldn't allow you to see without light. So I think we need two more properties for vision modes: losRange and fovRange, which is either NONE (the FOV/LOS polygon radius is 0), LIMITED (the radius is the same as the Vision Range), or UNLIMITED (the radius would be infinite). Normal eye sight would be losRange: UNLIMITED and fovRange: NONE. See Invisibility would be losRange: NONE and fovRange: NONE, but the Vision Radius would be infinite (at least in dnd5e); See Invisibility doesn't allow you to see anything on it's own, it should only reveal invisible tokens that would be otherwise visible. That's why both ranges are NONE.
So how to merge vision mode attributes? I some cases it's pretty obvious. Lighting Levels: choose brightest. Multipliers: choose largest. Light visibility: choose visible. Some vision mode needs to be selected to provide the shaders somehow. We choose the largest fovRange and losRange and compute the FOV and LOS polygon.
Testing visibility would work like this I imagine. First we test whether the target token is visible based on the classic FOV/LOS check, without the special status conditions. If the token fails the test it's not visible.
If it succeeds this test, it's not visible right away either. Now the each vision modes special test is performed. One of them must return true, otherwise the token is not visible. The check of the Eye Sight vision mode would be true unless invisible status and other stuff. The condition of See Invisibility would be true if visible unless other stuff. Both of these examples have an infinite vision range, so I omitted the range check. The condition for Truesight would be true if in (truesight) range (even if invisible status) unless .... So each of special vision mode check would also perform an addition range check, whether the target token is within the range of this vision mode.
The only problem with this kind of visibility testing is that it doesn't really support senses like Life Sense, that only reveal creatures/tokens, but not the environment. But I don't think it's impossible to make it work