[#4351] Region Template auto targeting - #7181
Draft
thatlonelybugbear wants to merge 48 commits into
Draft
Conversation
…mplate` Adds a new `dnd5e.canvas.TemplatePlacement` API to handle placing shapes within a scene. This base API deals with basic shape data but the `fromActivity` factory method behaves similar to the old method on `AbilityTemplate` to create a full measured template region. The created regions are set up to work as similar as possible to the old measured templates, using `coverage` highlight mode and the user's color. When the area of effect count is larger than one, all of the shapes are combined into a single measured template. `TokenPlacement` has been refactored and much of its code has been shifted into a new `BasePlacement` class that is shared between the two canvas placement systems. Closes foundryvtt#6763
…egion` Rewrites both placement APIs to rely on core's `placeToken` and `placeRegion` mathods rather than a new implementation. Removes `BasePlacement` since there is no longer much shared code.
Finds all applications that are not minimized, have a frame, and are not detached and minimizes them until placement is completed. This behavior can be disabled using the `minimizeWindows` option in the placement configuration. Also adds a `restoreLayer` option to the configuration to control whether the original canvas layer is made active after placement. Both of these options are enabled by default. Closes foundryvtt#6763
…if any have a clear wall ray to the tokens space
thatlonelybugbear
force-pushed
the
feature/regions-auto-targeting
branch
from
June 23, 2026 22:46
1d82035 to
f442dbb
Compare
… to templates (foundryvtt#6761) * [foundryvtt#5559, foundryvtt#6722] Add Activity Behaviors that attach to templates Adds a new system for registering Activity Behaviors. These will be automatically attached to any measured templates created from that activity. An Activity Behavior represents a simplified data model for configuring a Region Behavior, allowing for certain parts of the Region Behavior's configuration to be automatically populated based on activity settings (for example, the Difficult Terrain behavior gets its "Magical" property set automatically based on whether the item has the magical property set). Since players cannot create region behaviors themselves, the creation of these behaviors is handled by the active GM user after the player places the template in the scene. Closes foundryvtt#6722 * [foundryvtt#5559, foundryvtt#6722] Clean up behavior context, fix typos & localization * [foundryvtt#6722] Fix applied behaviors section not appearing if empty * [foundryvtt#6722] Switch to `TypeDataField5e` for configs, fix form * [foundryvtt#6722] Remove some unused imports
…ior (foundryvtt#6798) * [foundryvtt#5559] Add activity behavior for Apply Active Effect behavior Adds a new activity behavior that creates core's Apply Active Effect Region Behavior. * [foundryvtt#5559] Swap to system behavior, add sizes & types support * [foundryvtt#5559] Fix typo in config, JSDoc typos * Fix issue with `TypeDataField5e#_migrate`
…ities (foundryvtt#6800) * [foundryvtt#6641] Allow standalone AE documents to be linked to activities Adds a new `uuid` field to applied effects data on activities which allows the effect to be retrieved from a compendium rather than from the item. This is breaking change for `Activity#applicableEffects`, which now returns the effect profiles rather than the effects themselves. A new method `getApplicableEffects` has been added that retrieves the actual effect documents and is async so it can get them from the compendium. Closes foundryvtt#6641 * [foundryvtt#6641] Clean up some code & docs issues * [foundryvtt#6641] Add type restriction on UUID field * [foundryvtt#6641] Expand remote support to Enchant activity - Adds support for remote enchantments in `EnchantActivity` - Activity sheets now define what AE types they support - Removed separate enchantment template in favor of sharing the standard activity effects list template - Reworked `EffectApplicationElement` to not use `async` in the `connectedCallback` - Fixed application of effect start time * [foundryvtt#6641] Move supported effects into data, adjust existing effects * [foundryvtt#6641] Remove unused `SUPPORTED_EFFECT_TYPE`
Contributor
|
Is there any feasibility in allowing evaluation of the |
Contributor
Author
I have this working in my local version but not added in this PR yet (all of this was included in a module I was working on). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does. Probably too many things...
Relevant to #4351 for the Template Targeting
If I know how far the system is willing to go, I can adjust accordingly