PDA

View Full Version : Effect FX (5E)



jkeller
June 16th, 2026, 15:34
Forge (https://forge.fantasygrounds.com/shop/items/3394/view)

This 5E extension provides customizable icons for conditions (or any other effect) on a combatant.
Icons are automatically added/removed as the effects are added/removed.

Several options control the icon size (small, medium, or large), style (off, boxed, or icons),
position (which token corner), and flow (up/down, left/right, clockwise/counter, star).

https://i.ibb.co/bjhp8NM2/Effect-FX-Options.jpg

The icons are added on separate map layers, but will move with the map token, and are removed if it is removed.

Two versions of icons are provided for most effects, but if you have an image you prefer,
you can override these by dragging an asset (token or image) onto either of the existing FX buttons.

New effects can be added using drag-and-drop. Drag an effect onto the UI (onto any existing effect name)
to add a new row, then drag an asset onto the default red circle to specify the FX you want.

https://i.ibb.co/S8Y5sjx/Effect-FX-Icons.jpg

bwatford
June 17th, 2026, 05:02
I’ve been testing the EFX Core extension and ran into an issue where the visual effect layers are rendering underneath the tokens instead of around them.

After some investigation, I believe the root cause is that EFX uses `Image.addLayer()` (with type `"image"`) to draw the effect assets on the map. In Fantasy Grounds, map layers render below tokens, so when the positioning logic places icons at roughly `tokenSizePx / 2`, they end up covered by the token graphic.

I’m also seeing conflicts when the 5e Indicators extension (Status Indicators) is loaded at the same time. Indicators uses `token.addBitmapWidget()` to attach its health/death/save/target icons directly to tokens, while EFX uses map layers. Both extensions listen to effect changes, which causes overlapping behavior and makes the layering problem more noticeable.

A few specific observations:
- The current getPosition() logic with nOffset = tokenSizePx / 2 places icons right at the token’s edge/corners.
- Even with different flow options (circular/linear), the icons are frequently hidden behind the token.
- The 4th parameter being passed to Image.addLayer(..., 1) doesn’t appear to push the layer above tokens.

Would you be open to updating the drawing system to use token.addBitmapWidget() instead of (or in addition to) Image.addLayer()? That approach tends to play much better with other token widget extensions like Indicators and gives proper control via sendToBack() / bringToFront().

I’m happy to help test any changes if that’s useful.

Thanks for the work on EFX — the concept of custom per-effect visuals is really nice. Just hitting this layering issue when trying to use it alongside other extensions.

pindercarl
June 17th, 2026, 06:13
I’ve been testing the EFX Core extension and ran into an issue where the visual effect layers are rendering underneath the tokens instead of around them.

After some investigation, I believe the root cause is that EFX uses `Image.addLayer()` (with type `"image"`) to draw the effect assets on the map. In Fantasy Grounds, map layers render below tokens, so when the positioning logic places icons at roughly `tokenSizePx / 2`, they end up covered by the token graphic.

I’m also seeing conflicts when the 5e Indicators extension (Status Indicators) is loaded at the same time. Indicators uses `token.addBitmapWidget()` to attach its health/death/save/target icons directly to tokens, while EFX uses map layers. Both extensions listen to effect changes, which causes overlapping behavior and makes the layering problem more noticeable.

A few specific observations:
- The current getPosition() logic with nOffset = tokenSizePx / 2 places icons right at the token’s edge/corners.
- Even with different flow options (circular/linear), the icons are frequently hidden behind the token.
- The 4th parameter being passed to Image.addLayer(..., 1) doesn’t appear to push the layer above tokens.

Would you be open to updating the drawing system to use token.addBitmapWidget() instead of (or in addition to) Image.addLayer()? That approach tends to play much better with other token widget extensions like Indicators and gives proper control via sendToBack() / bringToFront().

I’m happy to help test any changes if that’s useful.

Thanks for the work on EFX — the concept of custom per-effect visuals is really nice. Just hitting this layering issue when trying to use it alongside other extensions.

bwatford is correct that tokens draw in front of layers.

I haven't looked at the implementation here, but something to consider is that when adding or deleting a layer it invalidates the image and forces a rebuild of the image. This may not be noticeable unless the map contains LOS or a significant number of lights. Rebuilding the image causes all of the LOS and lighting to be recalculated. BitmapWidgets have much less overhead than layers and do not force a rebuild of the image. Alternatively, I'm in the middle of updating the overlay effects system to better support persistent effects with the aim of improving extensions like Generic Action Layers. The token overlay effects provide similar functionality to the BitmapWidget, but with additional features. I'm happy to share, with either of you, more information on overlay effects—the current implementation and what new features are being added.

jkeller
June 17th, 2026, 14:13
Thanks for the feedback! I used layers intentionally here - not because I think it's the best way to show effects, but because I wanted to learn them for another extension I'm developing (Spell FX). The ability to scale and rotate is essential for that one. I agree bitmap widgets might be better for this one, and I'll investigate using them (but that will probably take a while).

That said, I could easily add an option to control the initial position distance from the token. Most of the tokens I tested with don't occupy the entire space, so there was not much overlap.

bwatford
June 17th, 2026, 14:19
That said, I could easily add an option to control the initial position distance from the token. Most of the tokens I tested with don't occupy the entire space, so there was not much overlap.

I tested with round tokens at 80% coverage, and the boxes were hard to see behind the token, you also might try tying into the native effects system that places markers on the tokens for effects and just override that since it is already setup for it.

jkeller
June 17th, 2026, 14:30
That sounds like a good idea for sure :)