5E - Better Combat Effects Gold

[bwatford]

Thanks, I have not heard of this extension before and I will take a look at it. Is there a way using this extension to not merely hard-set the AC to 16, but set 16 as the floor, so that if the AC would otherwise be higher than 16, the higher value is used?

If that was the case, just turn the effect off in the CT, as the spell no longer serves a purpose and that is less effects to be processed in the CT.

[Henix]

Hi,

I wanted to report an issue with the SAVEADD tag regarding the new native Exhaustion condition handling.

Currently, FGU handles Exhaustion natively on the effects tab, automatically upgrading it and handling the stacking logic (Exhaustion, EXHAUSTION: 2, EXHAUSTION: 3, etc.) when applied through standard UI/ruleset methods.

However, using

SAVEADD: Exhaustion

fails to apply the condition on a failed save. It seems like the programmatic effect injection used by SAVEADD might be bypassing the core ruleset's condition processing wrappers (like the ones handling the native auto-stacking hooks), or the text string isn't hitting the right listener to increment the existing tracker effect.

Would it be possible to look into aligning the SAVEADD handler with the new native Exhaustion effect? Thanks!


EDIT: my bad the NPC was immune that was why the exhaustion was not applied (i'm dumb xD)

[Henix]

Hi, I think I've spotted an issue with how standard core ruleset tags are parsed when Better Combat Effects Gold is enabled.

The Issue:
Standard attribute replacement tags like [INT], [STR], etc., are not being evaluated and replaced by their numerical values when an effect is added to the Combat Tracker. Instead, they are being added as literal strings.

Example Effect:

DMG: [INT]

Observed Behavior:
Testing in a clean campaign with EVERY other extension disabled:

• With BCEG Disabled: The effect parses correctly into the Combat Tracker (e.g., if the PC has a +4 INT modifier, it becomes DMG: 4).
• With BCEG Enabled: The effect lands in the Combat Tracker exactly as written: DMG: [INT], and the bracketed tag is never evaluated.

It seems like BCEG's custom effect-traversal or application hooks might be overriding or intercepting the core ruleset's standard handler before it has a chance to parse the bracketed attribute tags.

Has anyone else encountered this? Thanks!

[Darth Decisive]

I have, albeit with the [PRF] tag instead.

[SilentRuin]

I'd like some clarity on BCEG. Right now, to my knowledge, MW is the one making changing to BCEG after the large scale changes to effects logic in FG.

But what is the long term prognosis here? MW is with smiteworks and to my knowledge is not "inheriting" BCEG - but just getting it back to working as he did AURAs before Bwatford took it over.

No one has stepped up to take over BCEG. I for sure will not.

So question is - what is the long term stability for this heavily used extension if there is no one person actually managing? Sure, we see people asking for fixes - and I assume MW will address those as part of the port to insure it is back to working.

But what about longer term?

EXTENSIONS = RISK

Unsupported extensions though?

They = "soon to no longer work and fall by the way side".

Hence, what is the long term prognosis of BCEG?

[MrDDT]

Hi, I think I've spotted an issue with how standard core ruleset tags are parsed when Better Combat Effects Gold is enabled.

The Issue:
Standard attribute replacement tags like [INT], [STR], etc., are not being evaluated and replaced by their numerical values when an effect is added to the Combat Tracker. Instead, they are being added as literal strings.

Example Effect:

DMG: [INT]

Observed Behavior:
Testing in a clean campaign with EVERY other extension disabled:

• With BCEG Disabled: The effect parses correctly into the Combat Tracker (e.g., if the PC has a +4 INT modifier, it becomes DMG: 4).
• With BCEG Enabled: The effect lands in the Combat Tracker exactly as written: DMG: [INT], and the bracketed tag is never evaluated.

It seems like BCEG's custom effect-traversal or application hooks might be overriding or intercepting the core ruleset's standard handler before it has a chance to parse the bracketed attribute tags.

Has anyone else encountered this? Thanks!

I'm not seeing this issue at all. It's working perfectly for me.

I'm testing with version v6.0. No other exts.

Double check who's turn it is and how you are applying it.
Are you applying it from the action tab? or custom effects or is it adding it through an effect add?