Binding token attributes like states/bars/etc to properties and/or scripts

[melek]

Is your feature request related to a problem?

I often want to update token attributes based on a token property, but it requires event-driven macro systems to do so manually.

Here is an example of one such application to set up an automatic 'Death' system for monsters which would be a robust system that does not depend on Macros.

All rules apply to tokens of the 'Monster' property type.

• Binding a bar value to HP between 0 and MaxHP, hiding the bar at 0
• Binding the 'Dead' state to set when HP <= 0 or unset when HP >=1
• Binding 'Has Sight' to to set when HP >= 1 or unset when HP <= 0
• Binding the token's layer to 'Object' when HP <= 0, or to 'Token' when HP >= 1
• Binding token opacity to 50% when HP <= 0, to it's "user set value" when HP >= 1

I've come up with how I would design this, but I'm sure there are other, more gradual/less monolithic ways to approach the feature!

Describe the solution you'd like

This is the system to create these bindings in MapTool that I've come up with:

1. Bindings should be Campaign Properties. User interface to set bindings without macros for a campaign are important, as it would greatly increase accessibility of the feature. Macros to affect these bindings would be fine, but I would consider that on the same level as editing other campaign properties via Macro (something we don't really have at the moment).
2. Characterize bindings as a series of rules. This way, you could have a 'Bindings' tab in Campaign Properties to manage bindings in one place, probably with groups for organization.

• When adding a binding, you can select which attribute to bind (opacity? HP Bar? Dead state?), which Property Types and Token Type, Layers, and maybe even other filters like Token Size or Maps the rules apply to, a condition (either a 'simple condition' or a macro), and a state.
• Bindings can be re-ordered to dictate priority (top processed first).
• Binding rules don't have to cover all scenarios. For instance, 'Has Sight' might be bound to be unset when HP <= 0, but doesn't need a rule for HP > 0 - leaving the value to either fallback to a user-set value, or if no user-value is set, to remain unset until manually set.

2. Distinguish between 'bound' values and 'user set values'. This helps give control back to the GM over bound attributes for edge cases and strategic rule-breaking.

• Bound values are the calculated value for an attribute; User Set Values are when the value is set either by the GM / player directly or by the UI.
• Bindings can be configured to either fallback to User Set Values when none of their conditions are met, or be totally overridden by user set values.
• The GM should be able to hard-override a bound value in addition, perhaps with a flag for that particular token to have a binding overridden regardless of how it is configured. For the UI, this could be a flag for the whole token; in a Macro, this overriding could be more granular.
• There must be a macro and a UI component 'unset' User Set Values on a token/for particular attributes, which means when no conditions are met the attribute value doesn't revert to a set value.

2. Configurable fallback behavior. Bindings should each have a setting on whether "user set values" override the binding on that token, or
3. "User Set" values which can

Describe alternatives you've considered

Manually looping through tokens all the time one events like onTokenMove and onChangeSelection like a tedious pleb, slowing my games to a crawl when token quantities increase and constantly worrying about de-syncing my fragile house of cards.

Additional context

I want this type of capability to enable my Lib:Elevation library to be much faster by assigning states/opacities to token layer tokens, but I also eventually want that to be replaced by core functionality..

Still, I think this would be a boon to non-coding users and would be a lot of fun.

[melek]

Just want to note that this is somewhat related to #2860 (Bar Tracker) and the closed/duplicate feature #2552 - though this is a more comprehensive request.

[cwisniew]

Also related to (and dependant on) #720