Added hotkey macro button properties to metamacro functions

[bubblobill]

Identify the Bug or Feature request

resolves #4897

Description of the Change

included fields in metamacro functions for macro button properties "hotkey" and "displayHotkey"

Possible Drawbacks

conflicts in hotkey settings from different sources - buyer beware

Documentation Notes

Macro hotkeys and their display can now be set through metamacro functions.

Release Notes

Macro hotkeys and their display can now be set through metamacro functions.

---

This change is 

[cwisniew]

It should check to see if a hot key exists before setting it, any conflict should be resolved by not updating the hotkey. As a macro writer I don't know what hotkeys a user has set up and how dependant they are on said hotkeys so overwriting them could cause usability issues

[bubblobill]

I'm more a fan of buyer beware. Better to add a getMacroHotKeys() function and make the macro coder responsible.

[bubblobill]

Or stick hot keys in getInfo() if it isn't already present.

[bubblobill]

There you go. Now people can perform their own checks.

[FullBleed]

There you go. Now people can perform their own checks.

Glad you went with a new function.

[cwisniew]

I'm more a fan of buyer beware. Better to add a getMacroHotKeys() function and make the macro coder responsible.

This doesn't solve the problem, the hot keys user has set up should not be over ridden by macro. Just like macros should override people's themes.

[FullBleed]

I'm more a fan of buyer beware. Better to add a getMacroHotKeys() function and make the macro coder responsible.

This doesn't solve the problem, the hot keys user has set up should not be over ridden by macro. Just like macros should override people's themes.

I get what you're saying... but without getting into the whole argument of what GMs/Frameworks should be allowed to do when trying to impart a particular experience... why not provide user guardrails for features that could be problematic to them instead of stopping framework devs from doing stuff that many people would not care about?

In this case, allow the function, but add a check-box in Preferences>Accessibility to block macro changes to Hot Keys. Put it on by default. That way it will be on the game-runner to instruct players to disable the block... and up to the players to accept the request.

[cwisniew]

I'm more a fan of buyer beware. Better to add a getMacroHotKeys() function and make the macro coder responsible.

This doesn't solve the problem, the hot keys user has set up should not be over ridden by macro. Just like macros should override people's themes.

I get what you're saying... but without getting into the whole argument of what GMs/Frameworks should be allowed to do when trying to impart a particular experience... why not provide user guardrails for features that could be problematic to them instead of stopping framework devs from doing stuff that many people would not care about?

The guardrail is you can't override a hotkey that is already set :)
I guess we could add that option but, then which would framework developers prefer to happen by default none of their hot keys work or just the ones that are already taken? I can already tell you that if it gets put in settings people rarely know about it. I will start a discussion in discord and let people decide

The above function when a framework could check if its already set and not do it is not adequate because people developing frameworks wont check, then it gets reported as a bug then I would be inclined to fix it, then framework developers report it as a bug...

[bubblobill]

Fine then. I'll have it return false or something in the new props if it would have overridden an existing key. Party pooper.

[bubblobill]

Right then. Now the only way to change an assigned hotkey via macro is presumably to delete the hotkey holder before giving it to yourself. Assuming deleting a macro removes its hot key from the master list.