You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In essence, flags, but for Activities. Now that so much configuration has shifted from being on the item directly to being on Activities, it would be convenient for modules to be able to store data on the Activity pseudo-documents.
Example to follow:
Context:
Region Attacher, a module which (in dnd5e) allows the GM to pre-configure a Region's behavior and enable it to "attach" to an item-created template.
Simple example: a spell which shelters a 30ft sphere from rain. With 30ft sphere as the template type, and the "Attach Region" checkbox enabled, and the region itself configured with a behavior to suppress weather effects, casting the spell would result in a visual confirmation of the behavior described in the spell.
Previous Behavior:
On an Item sheet, when target type was one which would result in a template prompt, would show a checkbox & button to enable attaching & configure behavior.
Flags for whether to attach, as well as what the configured behavior should be, were stored on the Item under flags.region-attacher.
When the template was created, the origin Item (if it existed) was checked for those flags, and logic proceeded accordingly (creating a region with the region behavior(s) if necessary).
Desired New Behavior:
On an Activity sheet, when Area has a shape chosen, show checkbox & button in Area subsection to enable attaching & configure behavior.
Flags (or pseudo-flags, or whatever format of storing arbitrary data makes sense) for whether to attach, as well as configured behavior, will be stored on the Activity under ???.region-attacher.
When the template is created, the origin Activity (if it exists) is checked for those arbitrary data, and logic proceeds accordingly.
Potential workaround:
Store arbitrary data on the Item still, under flags.region-attacher.<activity_id>.
Difficulty here is that this would require either a more intrusive UX (a new application to handle this) or interception of the default update behavior (adding a checkbox to an Activity sheet and changing its value will attempt to update the Activity - would have to intercept this and instead update the parent item).
Thanks for your consideration.
The text was updated successfully, but these errors were encountered:
Another note on this: Currently, as both Activities & Advancements can be drag-n-dropped, doing so should result in a full transfer of relevant data. Unless I'm missing something in the code, the system's current solution (of creating a flag on the item by activity ID) would require custom handling for a drag/drop to grab the flagged data from the parent item; while if the flags were stored directly on the pseudo-documents, it'd be a trivial copy of the data.
In essence, flags, but for Activities. Now that so much configuration has shifted from being on the item directly to being on Activities, it would be convenient for modules to be able to store data on the Activity pseudo-documents.
Example to follow:
Context:
Previous Behavior:
flags.region-attacher
.Desired New Behavior:
???.region-attacher
.Potential workaround:
flags.region-attacher.<activity_id>
.Thanks for your consideration.
The text was updated successfully, but these errors were encountered: