So I guess for everything not rebound by the user from that list except CHATLINK, DRESSUP, EXPANDITEM, and FOCUSCAST the value would just mimic the value of the modifier value for that “action” (although quite a few of those are not actually actions, but action modifiers).
I wonder what happens when you use something like CHATLINK in there with a value of SHIFT-BUTTON1 or EXPANDITEM with a value of SHIFT-BUTTON2?
Experimenting now.
Edited to add results:
SELFCAST changed to “ALT” in Interface panel.
CHATLINK discovered to be SHIFT-BUTTON1 with /run print(GetModifiedClick("CHATLINK"))
Created a test macro as follows:
#showtooltip
/cast [mod:SELFCAST]Caravan Hyena
Placed it on one of my buttons.
Alt key pressed, the icon changes from “?” to the correct icon for that spell.
Changed macro from [mod:SELFCAST] to [mod:CHATLINK ].
Shift key pressed, the icon changes from “?” to the correct icon for that spell.
Apparently it takes ONLY the modifier keys from whatever is defined as the keybind for the listed action and applies uses it in the “mod:” conditional.
I can actually see a use for this, although it’s a bit baroque. If you had a very long macro with lots of modifier clumps (like altshift or altctrlshift) you could conceivably shortcut some of those by redefining the bindings for some of the shorter commands in that list and use them as sort of set names for that set of mod parameters.
Okay, I didn’t say it was a particularly GOOD use for this but I can see it being useful.
It might also allow you to override, say, self-target in certain situations where you need to have the ability to use the modifier tied to that in a macro that needs to target someone or something else.
For my purposes, it’s enough that I know how to extract the modifiers for each of the “actions” listed and substitute them in my logic.
On the plus side, my “while the game is down” code all worked perfectly.
I now have macros parsed (not interpreted yet) completely.
This is one of my more complex ones:
["3"] = {
{
["cmd"] = "/dismount",
["cmdObjTbl"] = {
{
["conds"] = {
},
["cmdObj"] = "",
}, -- [1]
},
["cmdType"] = "S",
["rawLine"] = "/dismount",
}, -- [1]
{
["cmd"] = "/cleartarget",
["cmdObjTbl"] = {
{
["conds"] = {
"[help]", -- [1]
"[noharm,exists]", -- [2]
"[dead]", -- [3]
"[mod]", -- [4]
},
["cmdObj"] = "",
}, -- [1]
},
["cmdType"] = "S",
["rawLine"] = "/cleartarget [help][noharm,exists][dead][mod]",
}, -- [2]
{
["cmd"] = "/targetenemy",
["cmdObjTbl"] = {
{
["conds"] = {
"[help]", -- [1]
"[noexists]", -- [2]
"[noharm]", -- [3]
"[dead]", -- [4]
"[mod]", -- [5]
},
["cmdObj"] = "",
}, -- [1]
},
["cmdType"] = "S",
["rawLine"] = "/targetenemy [help][noexists][noharm][dead][mod]",
}, -- [3]
{
["cmd"] = "/petautocaston",
["cmdObjTbl"] = {
{
["conds"] = {
"[nogroup:raid]", -- [1]
"[@focus,exists,nohelp]", -- [2]
"[@focus,noexists]", -- [3]
"[@focus,dead]", -- [4]
},
["cmdObj"] = "Growl",
}, -- [1]
},
["cmdType"] = "S",
["rawLine"] = "/petautocaston [nogroup:raid][@focus,exists,nohelp][@focus,noexists][@focus,dead]Growl",
}, -- [4]
{
["cmd"] = "/click",
["cmdObjTbl"] = {
{
["conds"] = {
},
["cmdObj"] = "ElvUI_Bar5Button10",
}, -- [1]
},
["cmdType"] = "S",
["rawLine"] = "/click ElvUI_Bar5Button10",
}, -- [5]
},
Edited to add: I’ve been testing the limits of this whole [mod:SELFCAST] pattern and there are a few.
-
It doesn’t appear that you can aggregated them - that is, while [mod:altctrl] works just fine, [mod:SELFCASTFOCUSCAST] (where self is alt and focus is ctrl) does not.
-
You can, however “or” them - as in [mod:alt/ctrl] and [mod:SELFCAST/FOCUSCAST] works just fine with them set to alt and ctrl respectively. The behavior of this when one of them set to “NONE” is anomolous, however. Instead of “or”-ing nomod and alt, the nomod part is simply ignored, so Blizzard’s coding motto, “Inconsistency is better than no consistency at all” seems to be actively in play here.
-
The “NONE” option in the interface panel apparently causes the conditional parsing code to branch somewhere. “No modifier” in the macro api is [nomod] but when a conditional is coded [mod:SELFCAST] where self is set to NONE, it behaves as if you’d coded [nomod] (which works) rather than [mod:NONE] (which does not). so the game is not simply pulling the value from GetModifiedClick(“SELFCAST”) and inserting it. It’s altering [mod:SELFCAST] to be [nomod] instead (something I can easily do).
I think I have everything I need from this thread to continue. I can see that I’m either going to have to explicitly NOT support actions as modifier parameters or I’m probably going to have as much code to deal with them as I have in about half the rest of the addon.
Thanks all.