LIGHT Effects - Round to Nearest Distance Multiplier(?!)

[rocketvaultgames]

Is there any way to make LIGHT effects round to the nearest 0.1 like they do in the Token Light section of the image panel?

I'd really like to use the following (as it's easy to toggle on/off and stays on the actor when they change maps):

LIGHT: 22.5/22.5 FFFFFFFF


Unfortunately, decimals aren't recognized, and whole numbers round to the nearest 5(!).

I can recreate the effect above in Token Light with Bright: 22.5, Falloff 1.0, Dim: 22.5, Falloff 1.0, but then I need to recreate it on every new map.



Bonus issue: TAB/Shift-TAB don't move among fields in the image panel...

[Moon Wizard]

The light effects are designed to work in grid units.

Regards,
JPG

[rocketvaultgames]

The light effects are designed to work in grid units.

Regards,
JPG

If decimals were supported, grid units would still work as-is, but it would allow things like, for example: light extending to the edge of a square instead of to the center of it...

Decimals are supported in Token Light... so the same thing can be achieved currently... just with a lot more tedium.



...And in 5e, emanations should behave this way:

Emanation [Area of Effect]
An Emanation is an area of effect that extends in straight lines from a creature or an object in all directions. The effect that creates an Emanation specifies the distance it extends.

An Emanation moves with the creature or object that is its origin unless it is an instantaneous or a stationary effect.

An Emanation’s origin (creature or object) isn’t included in the area of effect unless its creator decides otherwise.



Excerpt from Daylight spell:

"Alternatively, you cast the spell on an object that isn’t being worn or carried, causing the sunlight to fill a 60-foot Emanation originating from that object. Covering that object with something opaque, such as a bowl or helm, blocks the sunlight."

[rocketvaultgames]

The light effects are designed to work in grid units.

Regards,
JPG

With a little (lotta) help with an extension I've gotten the rounding to work to the nearest 1 instead of 5 (assuming 5' grid).

I'm not sure why it won't work with decimals, but I'm assuming it's how the "." and "/" are parsed...

Regardless... 22 or 23 are much better than getting rounded to 20 or 25. (would still prefer decimals to be supported here as they are in the image panel!)


Question: Can you tell me the method for how it is determined if a token is visible to another token? Is it a percentage of the area of the square that must be illuminated? Or the token size and/or shape?

[LordEntrails]

Question: Can you tell me the method for how it is determined if a token is visible to another token? Is it a percentage of the area of the square that must be illuminated? Or the token size and/or shape?
Unless it has changed it's the center point of the tokens.

[pindercarl]

With a little (lotta) help with an extension I've gotten the rounding to work to the nearest 1 instead of 5 (assuming 5' grid).

I'm not sure why it won't work with decimals, but I'm assuming it's how the "." and "/" are parsed...

Regardless... 22 or 23 are much better than getting rounded to 20 or 25. (would still prefer decimals to be supported here as they are in the image panel!)


Question: Can you tell me the method for how it is determined if a token is visible to another token? Is it a percentage of the area of the square that must be illuminated? Or the token size and/or shape?

If the token (as defined by its size) intersects with light, it is considered illuminated. The lighting is sampled at roughly 20% of the grid size. Line-of-sight visibility and mask visibility are calculated similarly.

Edit: To clarify, the size of the token is the rectangular bounds of the rendered token.

[rocketvaultgames]

Unless it has changed it's the center point of the tokens.

That doesn't seem right...

Does the size listed in the statblock matter at all?

Does dim vs. bright light matter at all?

I would guess 'no' to both...



I'd just like to understand the rule so I can know what I should expect the players to see in any given circumstance.


The "Player Vision Preview" mode is helpful in many instances, but there is no GM mode that will actually show exactly what the player sees (even non-vis NPC tokens are seen by the GM on a map).

Player on the left, GM on the right: No extensions. player has no darkvision, just the effect: "LIGHT: torch". LOS and Lighting ON. No ambient light. Distance Multiplier: 5, The NPC is size "Small" in its statblock.

https://www.dropbox.com/scl/fi/7r54yi3w5x20rpdbdgpv9/Recording-2025-08-14-123548.mp4?rlkey=qioue8den07xa5i8niotvxx9m&dl=0

[rocketvaultgames]

If the token (as defined by its size) intersects with light, it is considered illuminated. The lighting is sampled at roughly 20% of the grid size. Line-of-sight visibility and mask visibility are calculated similarly.

Edit: To clarify, the size of the token is the rectangular bounds of the rendered token.

Thank you for the reply. That still doesn't seem to jibe with what I'm seeing in this video: https://www.dropbox.com/scl/fi/7r54yi3w5x20rpdbdgpv9/Recording-2025-08-14-123548.mp4?rlkey=qioue8den07xa5i8niotvxx9m&dl=0


It's certainly possible I'm just not understanding something obvious here...


EDIT:

I missed the rectangular bounds part. I think it makes sense now.... ANY amount of light on the rectangular bounds of a token will make if visible to the player.

This can create situations that appear strange with a large circular token that seems definitely out of sight at a glance, but has it's transparent corner in the light... but at least I understand how it works now and can plan around that rather than being surprised.

Sincere thanks for your reply!

[pindercarl]

Thank you for the reply. That still doesn't seem to jibe with what I'm seeing in this video: https://www.dropbox.com/scl/fi/7r54yi3w5x20rpdbdgpv9/Recording-2025-08-14-123548.mp4?rlkey=qioue8den07xa5i8niotvxx9m&dl=0


It's certainly possible I'm just not understanding something obvious here...

I have to look at replicating your test when I have a moment. To more accurately test, I recommend using a square token so you can visualize the edges of the token.

[rocketvaultgames]

I have to look at replicating your test when I have a moment. To more accurately test, I recommend using a square token so you can visualize the edges of the token.

I don't currently think there is an issue (see my edit above).

[rocketvaultgames]

I have to look at replicating your test when I have a moment. To more accurately test, I recommend using a square token so you can visualize the edges of the token.

Alright... I take that back... there is one issue. The illumination doesn't take elevation into account:

65155

65156

Thus, a torch currently provides light in a cylinder with infinite height in both positive and negative directions, rather than a sphere.


Targeting distances do take elevation into account, but light does not.

[pindercarl]

Alright... I take that back... there is one issue. The illumination doesn't take elevation into account:

65155

65156

Thus, a torch currently provides light in a cylinder with infinite height in both positive and negative directions, rather than a sphere.


Targeting distances do take elevation into account, but light does not.

That would need to be a feature request.