[FREQ] onStateChange

[RPTroll]

We often change states in macros but wondering if it might be easier to fire macros based on a state change. Thoughts?

[JamzTheMan]

It could be useful. I find one 'issue' is we have macros in our framework that, say, sets vision off and sets 'blind' state on. But then the GM clear's states for some reason but vision would still be off.

Would it be better/friendlier to add a few options to 'States' instead so on a per state you can add a macro that is ran onChange, onSetOff, on SetOn (or better names)?

Although setting by group may be nice as well. eg you have Elevation states _1, _2, etc where you just want to do xyz if any of those states change.

[aliasmask]

I find hunting down the right state to manually change it cumbersome in most cases. I usually have a macro to set the state rather than the other way around. The only thing I can think of where this could be useful is to prevent players from changing the state on their own.

[wolph42]

you only have two options: either you set it manually or you use a macro. And TBH I have to agree with AM, 'manually' in my case means that I use a macro (that is: one macro that shows me all states, grouped per type and with checkboxes and icons).
Now I don't really see the added value to fire an extra macro when I run a macro so this would only be useful for those that (really) manually set a macro. I don't need it, but you can wait for other to react to this.

[JamzTheMan]

Maybe an option to "Hide" states instead?

eg Do not show the state on the menu so it can only be changed via macro?

[RPTroll]

I still use the state menu and I assume most of the new folks do as well. I change states a good bit as part of my framework. I also set states via macro. It would just be nice to encapsulate the code behind a state change with the state change itself.

In my mind, the state on the token should represent 'truth' about the state of the token and thus should be the trigger for whatever happens when that state is (un)set. It's just cleaner.

[JamzTheMan]

Yep, I hear ya.

There probably isn't a reason we can't do any or all of it at some level. Binding "Macro's" to a "State" may seem "easier" or more user friendly for new people. Dunno.

Not really taking this as "Lets give MapTool more power/new features" but rather "What would make it more user friendly for new macro/framework developers".

[RPTroll]

We'll leave it on the back burner for now. I may add it to the feature list to see if someone wants to pick it up.