#SWADE Illuminator

1 messages · Page 1 of 1 (latest)

heady obsidian
finite urchin
#

Thank you for this, I was dissappointed to learn the base systems support for sight and illumation is lacking to say the least. This is going to help a lot with my upcoming games.

heady obsidian
#

You're welcome! Please feel free to share your experiences with it. I'd love to see how well it works (or doesn't work) for others

tawdry nest
#

I have a request for this (assuming it's not already there). Can you add a way to visualize the illumination zones or maybe see the value for a given tile/location? It would be useful both as a debugging tool but also as a way for users to know exactly what the penalty would be for a given space.

heady obsidian
#

Oof. I’m not sure. It’s just using whatever lights the GM sets up on the scene, so if the GM sets more distinctive shades on the light, that could help some, I think. I’m totally unfamiliar with how lighting works code-wise, but what might be interesting is if there were borders drawn in where Dim and Bright end on a given light source.

tawdry nest
#

Well, ignoring the more complex visualizations, would it still be difficult to do a per tile thing? Are you not already doing position based checks to know the light situation of a token or is that done some other way?

heady obsidian
#

Here's the code I'm using to detect what light the Token is in. It checks if the Token's center is within the shape of the light any lights. Then it determines if the light is bright. If not, it then assumes it's dim light.

// This function determines what kind of illumination from nearby light sources the token is in.
function getProximityLight(token) {
    let c = Object.values(token.object.center);
    let lights = canvas.effects.lightSources.filter(src => !(src instanceof foundry.canvas.sources.GlobalLightSource) && src.shape.contains(...c));

    // If there are no light sources, just return false
    if (!lights.length) return false;

    // Determine if the token is in any bright light.
    let inBright = lights.some(light => {
        let { data: { x, y }, ratio } = light;
        let bright = foundry.canvas.geometry.ClockwiseSweepPolygon.create({ 'x': x, 'y': y }, {
            type: 'light',
            boundaryShapes: [new PIXI.Circle(x, y, ratio * light.shape.config.radius)]
        });
        return bright.contains(...c);
    });

    // If it's in bright light, return 'bright'.
    if (inBright) return 'bright';

    // Otherwise, the assumption at this point is that it's in dim light.
    return 'dim';
}
#

So it's not really a check of whether or not the square is in light.

tawdry nest
#

And then I assume it falls back to whatever the darkness setting is compared to what the dim/dark/pitch thresholds are?

#

If it's not in a light, I mean.

heady obsidian
#

Right, if it's not in any light, then it just suggests the global darkness level

#

It'll also suggest any penalties for lighting situations of any targeted tokens

#

Those tokens run through the same function as above.

tawdry nest
#

Yeah, it seems like it would be pretty easy to use this logic to figure out the illumination of any given position (it's literally what you're doing already), the difficult part is figuring out how and when to show it.

#

Hmm. I'll put some thought into it and see if I can come up with any clever ideas.

heady obsidian
#

SWADE Illuminator v1.0.1

  • Fixes disabling of threshold settings feature when automatic penalty suggestions are disabled in the settings.
heady obsidian
tawdry nest
#

Yeah, it's a good point. When I originally asked for it, I was under the impression it was a bit more complex than it is.

I mean it still should be trivial to get the illumination for a given position, grid or not, but it feels less necessary now. As you say, if you could see the radii of bright and dim lights, you should mostly be able to figure out the illumination at a glance. It gets complicated once you take into account walls, regions, and dark light sources, though.

heady obsidian
#

Walls should block light, meaning the token's coordinates wouldn't be within the shape, I assume.

#

I actually haven't tested dark light sources yet. I probably should. Gonna do that now actually.

#

Walls do their job

#

Oh crud. I need to account for dark sources even if global is bright. I currently don't even bother running the script if global is bright. facepalmpicard

heady obsidian
#

OK, I just discovered that light vs. darkness prioritization values will determine if a token is in darkness or not.

#

That makes things much simpler

heady obsidian
tawdry nest
#

That is interesting. I wonder how those can be used given that lights only have bright and dim.

heady obsidian
#

From what I can tell, and I very well could be wrong, halfdark and darkness are the equivalent of dim and bright respectively, but for darkness. I'm not sure what "brightest" means though

#

The problem I'm stuck on right now is the scenario in which the dark and light powers intersect. I don't know how to do anything about it visually, but I'm trying to get it to interpret as dim light as per the description of the power(s). The problem is, In order for light to pierce darkness, it has to have a higher priority, but then it doesn't register as the the darkness' shape containing the token's point.

#

So I need to figure out another way to derive that they're intersecting.

heady obsidian
#

@fair sparrow any thoughts on how to determine if a token with a higher priority bright light is in the radius of a darkness source?

fair sparrow
#

Hmm. I haven't really looked at the lighting priority stuff yet, so can't say for certain

heady obsidian
#

So, I think I have this all working, including accounting for walls. All I want to do now is change how prioritized light (assuming it's the light power) and darkness blend where they intersect, if possible. I have no idea how to do that though.

heady obsidian
#
  • Fixes error when Global Illumination Darkness is set to 0.
  • Darkness detection now takes into account if a light source has higher priority than a darkness source in proximity (i.e. light power interactin with dark power), and sets the modifier for Dim Light (as per the light/darkness power description).
    • Note that Foundry VTT does not render this overlap as Dim light but instead prioritizes one source over the other and treats the Token as if it's not in any amount of darkness.
  • Correctly ignores inactive sources of darkness or light.
lapis spindle
#

@heady obsidian I don't know if SWADE Illuminator is still a going concern, but I sent a PR to upgrade it for swade 5.1.0's changes if you're interested.