Can you make a rolling Macro?

Okay, there are two ways to do this. This first is to define a list of macros, and then use a rolling keybind to powexec the slots the macros are in. This is by far the most robust, as it allows you to edit the macros in your tray instead of having to exit to edit the keybind file. The drawback is, you have to take up a bunch of tray slots for it.

What I like to do, for example, is define a set of 10 macros in my tray 5. These are my Taunt macros, they say something, then Taunt. I then have a keybind that uses a bindfile to activate powexec_tray 5 <#> and then load the next bindfile with the next slot number.

If you REALLY want a rolling macro, though, there is a way to do it, and it takes advantage of a bug. This bug may not be present in later patches, so I'll warn you it might not always work. But for now, it works, and I use it a lot.

You can use a bindfile to create a macro. The secret is to put a $$ command at the beginning of the line to "capture" the bind command. The rest of the line will be executed as if you typed it in on the command line.

Say you create a text file that looks like this:

$$goto_tray 5
$$macroslot 0 Taunt1 "say Come get some!$$powexec_name Taunt"
$$macroslot 1 Taunt2 "say Get ready for a beating!$$powexec_name Taunt"
$$goto_tray 1

When you load this bindfile, with bind_load_file, instead of binding keys, it will execute the commands, going to tray 5 and dropping two Macros into the first two slots. This is just an example, but it shows how I often define my taunt macros for my characters. It demonstrates the idea, though. The $$ at the start separates the bind (which is blank) from the remaining commands. This will output some error messages, but you can ignore them, and I think there was a guide around here somewhere which showed you can put a bind there of some kind to keep the error message from coming out. I'll see if I can find it.

Anyway, to actually make this macro "rolling", you would actually have to load the bindfile in the execution of the macro itself. For instance, this is the macro I use to activate Domination. It uses two files, and activates Domination and does a costume change with the first press, and changes back to the original costume when I press it again. (I press it the second time manually when Domination ends)

file #1: dommacro1.txt
$$macroslot 9 Dom "cc 1$$powexec_name Domination$$bind_load_file dommacro2.txt"

file #2: dommacro2.txt
$$macroslot 9 Dom "cc 0$$bind_load_file dommacro1.txt"

You would then bind_load_file dommacro1.txt to create the macro. The first click on the macro would change to the second costume, activate Domination, and then reload the macro with the second definition. The second click on the macro changes back to the first costume, and reloads the first definition.

In this case, I didn't use goto_tray because I have this macro in my main tray. I'm also not 100% sure about the numbering order, the last slot may be 0 and not 9. Experiment with it to see what works. I do know that powexec_tray does not work on the last slot in any tray, you have to goto_tray and use powexec_slot to activate it. But you can ignore that as long as you don't use the last slot in the rolling keybind solution I posted above.

This really can't use for botting since each click of the macro can only redefine the macro once. You have to keep clicking for it to keep "rolling", just like with a keybind. However, as long as the bug continues to exist, this should continue to work.

I am actually hoping the devs give us a "macro_load_file" and "macro_save_file", as it is annoying this is a one way transfer. You can use a bind file to define a bunch of macros, but they have to be written in the text file and cannot be saved again if edited. As I use a LOT of macros, it can be difficult to keep a copy of them saved so I can restore them if something happens to them. And again, this could not be used for botting any more than bind_load_file can.

BTW, anyone wondering how the /macro "Slap" "e smack$$e slap" works, or something like it, basically in any given keybind or macro only ONE Power or emote may be activated at a time. (Anything with an animation) That activation, whatever it is, will be queued up to take place as soon as your current animation ends, just like if you clicked on a power. The LAST command in the string is the one that will take place, unless that power is already active, at which time the NEXT to last one will switch on, and so on.

In other words, if you have a macro "powexec_name Hover$$powexec_name Fly", this will activate Fly first, then toggle between Hover and Fly because the second activation will turn OFF Fly and ON Hover. Note than any number of powers may be turned OFF at one time, but only one can be toggled ON.

The powexec_toggleon/off commands can be used to refine this, for instance "powexec_toggleon Ninja Run$$powexec_toggleon Sprint" will turn ON first Sprint and then Ninja Run, with each press of the macro. Once both are on, the macro will have no more effect. "powexec_toggleoff Ninja Run$$powexec_toggleoff Sprint" will turn them BOTH off with ONE press.

Emotes seem to confuse the issue, and in fact, if you combine an emote with a power, you will get the power animation half the time, and the emote half the time. It can be quite wierd. I've found a costume change emote (cce) seems to always override the power activation. I use this to make my genie grow wings with a puff of smoke when she turns on Fly.

Using the command powexec_auto will let you activate TWO powers with one press. "powexec_name Air Superiority$$powexec_auto Brawl" will immediately activate Air Superiority, causing it to hit your target if you have one, and then queue up Brawl on autofire. This will then fire as soon as Air Superiority ends. The drawback is a) if you don't have a target, Air Superiority will select one, but then I think Brawl will hit it and b) Brawl will continue to autofire every time it recharges, unless you hit the Z key. (Or whatever is bound to "powexec_abort")

"powexec_unqueue" will unqueue whatever attack is currently in the system, WITHOUT removing whatever power is set to autofire. (Only one power can be set to autofire) This can be useful, especially for starting a command where you want to ensure there is no current power queued up. (For instance, if you want to ensure a particular power is executed first in a chain even if it is CURRENTLY set to execute)

And just to say it, the "bug" above will cause all of the commands executed in the bindfile described above to follow the same rules, so if you actually try to activate any powers with that bindfile, only one of them will execute. Any number of macroslot commands can be carried out, though, just like any other command that doesn't activate an animation.

Can you add a macroslot command to a macro? That might make for some tricks.