Skip to content

[Feature] ActionConfig - Granular Outcomes#1880

Draft
WBHarry wants to merge 78 commits into
epic/granular-action-outcomesfrom
feature/granular-action-outcomes
Draft

[Feature] ActionConfig - Granular Outcomes#1880
WBHarry wants to merge 78 commits into
epic/granular-action-outcomesfrom
feature/granular-action-outcomes

Conversation

@WBHarry

@WBHarry WBHarry commented May 14, 2026

Copy link
Copy Markdown
Contributor

No description provided.

}

static addDamage(_event) {
static addDamage(_event, button) {

@CarlosFdez CarlosFdez May 15, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a general thing in the codebase, but do you mind if we rename actions like these to #onAddDamage? It differentiates from methods invoked to do things, and its also the convention used by the core foundry codebase.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose we could, although it does feel like becoming the villain of my own story.

In the case of Foundry, I detest the use of #. It's always the reason we end up needing to copy some 5 extra methods when we want to override just 1, as it's not possible to reference the private methods from outside.
In our case it's probably less of an issue though as our classes and dialogs aren't intended to be overwritten.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the important thing is starting with on. If using # makes you uncomfortable we can avoid it. Let me know.

The main benefit of using # is being able to make changes without being concerned about something being part of a public interface. I am in agreement when functionality can't be replicated.

@CarlosFdez
CarlosFdez force-pushed the feature/granular-action-outcomes branch from 87a7a75 to 1af377b Compare May 16, 2026 01:22
CarlosFdez and others added 18 commits May 15, 2026 21:29
* Fix visual quirk with blur in unfocused countdown

* Snuck in fixes and refactors
* Preload ancestry and community features in description

* Corrected comments

---------

Co-authored-by: WBHarry <williambjrklund@gmail.com>
…er data is used over that in the levelup data if available (#1971)
)

* [Feature] Configurable starting gold amounts in Homebrew settings
WBHarry and others added 30 commits June 16, 2026 18:13
* Made trigger errors more informative

* .
* Fixed so that automated countdowns reverse progress from Fear when rerolling dice if the duality result changes

* .

* Removed overprep

* Apply suggestion from @CarlosFdez

---------

Co-authored-by: Carlos Fernandez <CarlosFdez@users.noreply.github.com>
* .

* .

* Apply suggestion from @CarlosFdez

---------

Co-authored-by: Carlos Fernandez <CarlosFdez@users.noreply.github.com>
* Simplify ActiveEffect sheet tags

* Show origin actor and exclude tag if it is a top level actor tag without origin
* Fixed so that damageParts without an applyTo field is assumed to be hitPoints

* Added the applyTo field to the basic attack for Adversaries and Companions

* Tentative blindfix to issues of entities being null. Can't replicate it

* Added some safety for missing things if someone was on a REALLY old system version and then updated all the way

* Moved v13 countdown migration over to a migrateData

* .
* Fixed logic for picking which actor to summon

* Moved getWorldActor function to utils and updated logic

* .

* Improved logic
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants