Macros to get/set/update/delete campaign properties.

[melek]

Is your feature request related to a problem? Please describe. Drop-in libraries and framework installation/upgrading sometimes require users to add states, bars, sights/lights, and properties to their campaign properties.

Currently we can get/view campaign properties with a variety of functions, but we still need the Create, Update, and Delete functionality to really make a true drop-in library that doesn't take the user work to set up.

Describe the solution you'd like I want a suite of functions that let us get and update token properties in a consistent, simple way. Specifically I want to be able to update:

• Property types and Property Text
• Property text / full access to line items - order in property list, name, modifiers, abbreviation, and default value
• Bars
• States
• Sights
• Lights
• Repositories

Campaign Property       | Getter            
Token Props         | Partial * 
Token Props (Names)     | getAllPropertyNames()
Token Props (Names **)      | getLibPropertyNames()
Token Props (Types)     | Not available **
Lights              | !getInfo("campaign")
Sight               | !getInfo("campaign")
Bars                | !getInfo("campaign")
Bars (Image)            | getBarImage() 
States              | Partial *     
States (Groups + Name)      | !getInfo("campaign")
States (Image)          | getStateImage()

! Part of JSON output.
* Only some data available via macros.
** May include names not in the campaign.
*** Can be partially surmised via Macros.

Granular functions are okay - but if a function close to getInfo("campaign") was implemented as getCampaignProps, maybe a unified function like setCampaignProps which accepts a highly structured JSON to add/update (and a way to delete) properties could provide a super simple interface for this feature.

Describe alternatives you've considered

• Remain unable to create extra tools and custom interfaces which update Campaign Properties, such as players being able to configure their own auras in a frame5 with previews and other community niftiness.
• Continue to give drop-in and framework users manual instructions to update their Campaign Properties like swine rooting for broken truffles among the sludge.

Additional context There are a great number of requests related to this. Here is

• Campaign Properties "import predefined" provides bad UX #1540: The Properties import feature is well-intentioned, but old and not great. This feature would give us a new way to import and even merge predefined campaign properties with a macro button (maybe even a self-destructing event-triggered macro!). This goes for Improved import/export of Campaign properties #2852 as well - and maybe whatever mechanism within MT that could accommodate these macros could also be used to facilitate selective property merges.
• Variable Auras or Sight #1954: Would be made possible via macros, though of course wouldn't be as cool as a native implementation.
• Enhancement: Macro functions to dynamically create light source and manage same #331: Would have many of the needs met regarding creating light sources on the fly, and the portability aspect could be simulated with structured data/properties and macros (could even be an on-token utility macro) to interpret and set "dynamic" lights when not present in a target campaign.
• Add a way to easy get find, install and update to MT-extensions #2924: Right now, updating libraries via macros is limited in that the user still has to do some manual work if any states/etc are needed for the update. Being able to set campaign properties could enable such tools like my abandoned Lib:Rat framework-updater library, and ease manually adding and updating (and removing!) add-ons/frameworks with one-click updaters.
• Ability to read/write/create/delete/etc. GM, Campaign, and possibly Global macro properties #2926: This is more of a companion request, but combined this request and #2926 would make one-click installation of whole frameworks very possible. Import a map, click on a setup macro, and bam - all tokens, macros, and campaign properties set/merged.

@cwisniew also has filed a suite of issues which might impact this request:

• CampaignProperties are not thread safe. #1247 - perhaps this needs to be done to protect performance of dynamically changing campaign properties (like Auras/Sight in #1954)?
• These related issues might be good opportunities to also implement these getter/setter macros:
  • Update the Campaign Properties -> Token Properties Tab #1238 -
  • Update the Campaign Properties -> Sight Tab #1239
  • Update the Campaign Properties -> Light Tab #1240

[cwisniew]

One of the bigger stumbling blocks I see how to resolve the situation where more than one library wants to set the properties. If they are dependant on the properties they set up to work correctly, then none of them may function correctly. Merging conflicts is going to be far from trivial and even getting the merge 100% successful could still lead to errors in the macros.

[melek]

One of the bigger stumbling blocks I see how to resolve the situation where more than one library wants to set the properties. If they are dependant on the properties they set up to work correctly, then none of them may function correctly. Merging conflicts is going to be far from trivial and even getting the merge 100% successful could still lead to errors in the macros.

I agree, there is a lot of room to create conflicts.

I have a few ideas that might work. One of them is to keep all macro-defined campaign properties separate from user defined properties, where the user definitions always take precedence.

Instead of overwriting each other, macro-defined properties could be given a priority number. Property declarations with the same priority wouldn't be guaranteed to be executed in a specific order, but you could set a different priority to coordinate with other add-ons you want to be compatible with. Not perfect, but it is one way to make it possible to both customize the properties for a campaign (with the user set properties) and integrate with other libraries more dynamically.

A non-destructive approach actually sounds pretty attractive - but maybe there are some other ideas out there in how to design something like this for success.

[bubblobill]

vaguely related getInfo("token"), setInfo("token") #2306 Same principle, the power to break things comes with the power to do awesome stuff.

[melek]

I wanted to iterate this feature request a bit with a solution I think would be great for add-ons.

What if campaign properties could be defined at runtime in a cascading way, where the user-defined properties are the base, then new properties can be defined on top of those? Conflicts are still possible at runtime, but it won't ever mutate the user defined properties.

Instead of a 'priority' system to try to fenagle conflicts, it would simply be that the last definition of a term wins out.

I'd love feedback on this approach - I think it might be a less destructive way of doing things.

Edit: One odd case here is 'Deleting' a property. I think that defining a campaign property with no settings, {} or similar, might be the equivalent of saying "Treat this as though it doesn't exist" - alternatively, it could be that you can redefine but never "delete" (unset) a property definition at runtime.

[Azhrei]

The order that add-ons are added would be a problem. How can you resolve that? Any priority system that you create would still allow for conflicts, and there would be no way to know what other authors have done such that you could pick a proper priority for your own add-on. And it may be possible that you could want yours to be before add-on A and after add-on B, but only for some properties?!

[melek]

Just like onTokenMove requires compatibility troubleshooting, so would augmenting campaign properties.

An alternative, likely better, is a namespaced campaign property system where an addon can only interact with its own and the user-defined properties, and those properties could be edited per-addon. Campaign Properties connected with an add-on could be accessible or private, like macros.

[Tdue21]

I have to add that this functionality would be almost priceless to an add-on based campaign framework. By enabling creating and updating campaign properties, like token types, lighting etc. an add-on author can have everything contained within the add-on, instead of having to maintain mtprops files etc.

At the very least, it would be incredible helpful to be able to import campaign properties from a json file, instead of having to use a mtprops file.