+ Reply to Thread
Results 1 to 7 of 7
Like Tree4Likes
  • 2 Post By Rinsho
  • 1 Post By Rinsho
  • 1 Post By Rinsho

Thread: The Comprehensive Macro Guide

  1. #1
    RIFT Guide Writer
    Join Date
    Mar 2011
    Posts
    27

    Default The Comprehensive Macro Guide

    Disclaimer: This guide's purpose is to explain the how and why of macro making/mechanics. It is not meant to showcase optimal macros, list all macro commands, or the like - there are already threads for that (see: RIFT Community Guide Compendium).

    Table of Contents
    • Introduction
    • Macro Mechanics
      • Program Flow
      • Ability Queues
      • Modifiers
    • Aliases
    • Advanced Concepts
      • Cooldown Limitations
      • Order of Execution/Optimization
    • Tips
    • References

    Introduction
    This guide seeks to provide the community with the knowledge of not only how to make macros, but also why they work (or don't). All current guides I have had the pleasure of reading recently have listed commands and provided example macros, but not delved deeper into the reasoning behind macro ordering, the principles behind the macro's program flow, and in general do not provide a means for the average reader to create, debug, and optimize their own macros. This is what I intend to provide the community with this guide. Enjoy.

    Macro Mechanics
    In general macro mechanics as a concept covers the why of macros. What goes on behind the scenes, in what order does the macro execute - things of that nature. So without further adieu, we'll talk about the most important macro concept - Program Flow.

    Program flow is the term I use to cover the order that the macro executes. There are some rules that persist in all macros that are essential to know if you plan on making your own macros:
    1. Macro execution is from top to bottom sequentially. What this means is that the macro will start from line 1 and continue to line 2, line 3, etc until it reaches a "break" or the end of the macro at which the macro stops execution. As a side note, only commands that are valid and can be executed will be executed. If a skill is on cooldown, you are out of range, or there is any other reason the skill can not be executed it will be skipped.

      Advanced Description: RIFT uses a FIFO (first-in first-out) system to process the legal commands at the time of execution. This means that processing speed/latency does not impact the execution flow of your macro (even though sometimes visually it may appear that way).

    2. There are currently two known "breaks" in the RIFT macro system - /cast and /use. Generally speaking, it seems in the RIFT macro system any command which uses an item (consumable) and/or casts/activates an ability will function as a "break."

    3. Each macro operates independent of other macros (they have independent program flow). Also as a side note to this, a macro cannot call or use another macro. In addition, only one macro can be in operation at a time, so be careful with the use of /wait or /macrowait. You can, however, manually activate GCD/off-GCD skills/consumables while a macro is in the /wait or /macrowait stage.

      You can, for example, create a macro like:
      Code:
      #show Battlefield Intimidation
      wait 30
      cast Battlefield Intimidation
      Now cast Battlefield Intimidation immediately followed by activating this macro, and as soon as Battlefield Intimidation is off cooldown (cooldown of 30s) the macro's wait will be over and trigger it again (if you change "wait 30" to "wait 15" it will simply queue up Battlefield Intimidation - assuming you have Ability Queue set to Full, that is).

    This last point leads me to the next topic - Ability Queues. The settings for the ability queue can be found under Options->Settings->Interface->Misc. There is a drop-down box titled "Ability Queue" with options for None, Short, or Full.

    The ability queue visually appears as four glowing orbs around a queued skill. What this does is allow you to queue a skill to be used while there is some factor preventing it's current use. This is where the difference between Short and Full comes in. Short allows you to queue after half the GCD has expired, while Full allows you to queue at any time (skill is being cast, GCD is in effect, or the skill itself is still on cooldown). Full is the most macro-friendly setting, as the time constraint on Short requires precision timing.

    Ability queues are important to the world of macros. Macros do not give visual feedback on if something is currently queued, so the more relaxed the constraints on queuing are, the more reliable the macro will operate. This is especially apparent when planning to "queue macros", as is the case with mouseover macros. The first macro will activate a skill, and since mouseover macros typically only activate a single skill, you will want to use a second macro immediately to queue your next skill.

    The final topic I would like to touch on in this section is Modifiers. Modifiers are one of the arguments you can pass to commands. The currently known modifiers are [alt], [shift], and [ctrl]. These modifiers are the only current way to modify program flow in a macro. What happens is when you hold alt, shift, or ctrl and press a macro button, then the program encounters a command with that modifier, it will execute it. The two most common (and possibly the only) commands that make use of modifiers are /cast and /use (probably other "break" commands as well if they exist).

    This allows you to have multiple program flows within a single macro. As an example, let's take this macro:
    Code:
    #show Healing Breath
    suppressmacrofailures
    cast [shift] Healing Breath
    cast [alt] Healing Spray
    cast Healing Invocation
    What the above macro does is allow you to activate three different skills depending on what modifier you press with the macro. If you press shift and the macro button, you'll cast Healing Breath; alt and the macro button, you'll cast Healing Spray; if you press just the macro button, you'll cast Healing Invocation. Now let's consider the same macro without modifiers:
    Code:
    #show Healing Breath
    suppressmacrofailures
    cast Healing Breath
    cast Healing Spray
    cast Healing Invocation
    This macro has no modifiers, so pressing shift/alt/ctrl will have no effect on program flow. When you press the macro button, it will execute Healing Breath if it's off cooldown, otherwise it will execute Healing Spray. Since Healing Spray has no cooldown, the macro will never execute Healing Invocation.

    An important note to consider when deciding on whether to use modifiers or not, however, is the way you plan on activating the macro. If you plan on clicking the macro, using shift/alt/ctrl will work fine. However, if you plan on keybinding the macro (either on your hotbar or on a special hotkey), you need to make sure the modifier+keybind combination is not already in use.

    For example, if you have your second hotbar keys keybound to shift+number (shift+1 to shift+=) and you plan on using a shift modifier in a macro on your first hotbar (keybound to 1 to =), it will not work. Let's say you put the macro on the first hotbar in the first space (keybind: 1). If you press shift+1 you will activate the first space on the second hotbar, not the macro with the shift modifier. This is something to watch out for.

    Aliases
    Aliases are nicknames for commands. Currently (probably as a safety precaution) the alias system is extremely limited. If you type /alias in the chat window, the game is nice enough to show you the syntax - /alias <alias> <command> <args,...>. This may look confusing for those not familiar with programming, so I'll explain it with an example. Let's say we want to make an alias for "/cast @self Healing Breath" and want to name it selfHB. The alias command would look like this - /alias selfHB cast @self Healing Breath. Breaking this down, selfHB is the <alias>, cast is the <command>, and @self Healing Breath are, respectively, arg1, arg2, and arg3 (<args,...> means arg1, arg2, etc).

    Aliasing whole commands that you use frequently (whether in chat or in macros) is very convenient, but there are some restrictions and guidelines that aliases follow:
    1. As much as I hate it, "/alias sfm suppressmacrofailures" does not work. There seems to be some internal check to prevent suppressmacrofailures being directly used in anything other than a macro (even though it's being used in a macro as sfm, that's indirectly using it in a macro). It will give you a lengthy error message if you try.

    2. Alias names can not contain spaces (substitute an underscore if you want to use a space). For example, mcast and m_cast are valid, but m cast is not.

    3. Alias commands delimit on spaces. What this means is that RIFT uses spaces to determine what goes where. In the previous example about suppressmacrofailures, you'll notice there are spaces in between /alias, sfm, and suppressmacrofailures. These spaces RIFT uses to "break apart" the command into it's components. This is important because delimiters can not be a part of the components since they're discarded.

      The practical impact of this is when you attempt something like "/alias mcast cast @mouseover". Since delimiters are discarded, when you use mcast in a macro - for example "mcast Healing Breath" - this translates to cast @mouseoverHealing Breath. Another thing some people may be asking is - "Well why doesn't it translate to cast@mouseoverHealingBreath if all delimiters are discarded?" The reason behind this is they inject spaces between the arguments, but this is implemented on a per process basis. In the alias example, cast is arg1 and @mouseover is arg2. The system places a space between arg1 and arg2, so when mcast is used "cast @mouseover" is properly used. In the mcast example, Healing is arg1 and Breath is arg2, so when the command is executed "Healing Breath" is properly used. The problem is that the system does not place a space between a command and it's arguments (why would you normally), so the final command parses like this - cast @mouseoverHealing Breath.

      Now, some of the programmers out there may be wondering if they can use other representations of spaces instead. In fact, it looks as if you can from first glance, for example if you do
      Code:
      /alias mcast cast @mouseover&#32
      you'll see in the chat it adds a space after @mouseover ("cast @mouseover " instead of "cast @mouseover"). You'd think it would now correctly parse to "cast @mouseover Healing Breath", but alas, it doesn't work. Apparently RIFT doesn't convert &#32 into an actual space character because it stores the commands as raw strings. The only conversion takes place on output apparently. What this means is that the second command parses as
      Code:
      cast @mouseover&#32Healing Breath
      when it gets delimited, and since &#32 isn't a space character (until it's translated), the game thinks
      Code:
      @mouseover&#32Healing Breath
      is a single argument (you'll see the game display "unknown command: @mouseover Healing Breath"). So sadly aliases are not as strong as they initially appear, though they are extremely useful for conserving time with commonly used commands.

      Note1: The ; was removed from &#32 to prevent the forums from converting it into a space character.
      Note2: Other programmers more familiar with text manipulation may find out alternate methods, and if you do please inform me, I'd love to be able to shorten "cast @mouseover" to "mcast" since I use that command so much.

  2. #2
    RIFT Guide Writer
    Join Date
    Mar 2011
    Posts
    27

    Default

    Advanced Concepts
    The following two topics are about side-effects of the program flow of macros that are important to understand since they can cause extremely confusing bugs in your macro. The first of these topics is Cooldown Limitations.

    Cooldown limitation refers to the interaction between skill cooldowns, the GCD, and program flow. When a macro never gets far enough down the macro command list to execute a skill, this is a cooldown limitation. This is the primary reason why macros are made in "reverse order" in relation to their cooldowns. To avoid a cooldown limitation you typically want to order the skills from highest cooldown to lowest, though there are exceptions. This is also the reason why typically you can not have more than one non-proc no-cooldown skill in a macro as the skill should always be valid, therefore preventing execution of any skills below.

    If, however, you have a lot of skills in a macro or have re-arranged the commands to optimize execution order (the skills aren't in highest -> lowest cooldown order) you can ensure your macro will not suffer from cooldown limitations via an analysis:
    1. Determine time remaining before the cooldown refreshes by taking the cooldown and subtracting either the cast time or the GCD (whichever is higher): (skillCD - max(GCD/castTime))

    2. Determine the amount of time used by each successive skill by using either the cast time or the GCD (whichever is higher): (max(GCD/castTime))

    3. At the point in which the summation of the successive skills is equal to or greater than the cooldown refresh time by a GCD, no more skills after that will execute (assuming first execution). The exception to this being if one or more cooldowns on successive skills are longer than the initial skill's cooldown. Each skill which has a longer cooldown than the initial skill's cooldown will grant one extra skill per macro activation while it is on cooldown.

    4. You can apply these steps recursively to determine whether all areas of the macro will activate at some point and to also determine the execution pattern.
    An example to demonstrate the above principles:

    Each line is a new skill, CT = cast time, CD = cooldown
    Code:
    1) CT 0; CD 10
    2) CT 5; CD 8
    3) CT 0; CD 8
    4) CT 0; CD 6
    5) CT 0; CD 0
    The program flow:
    Code:
    1,2,3,4,2,1,3,2,4,3,1,2,3,4
    The final topic I'd like to discuss is Order of Execution/Optimization. This is a very general idea, and is the reason behind the exceptions in the cooldown limitations section above. Ordering cooldowns from highest to lowest may be the easiest way, but it is not always the optimal way. The program flow of macros is sequential starting from the first line, therefore you can easily optimize the order of execution by arranging skills in such a way that skills only activate when you need them to.

    Take for example a possible Justicar macro:
    Code:
    #show Bolt of Radiance
    suppressmacrofailures
    cast Bolt of Radiance
    cast Sovereignty
    cast Precept of Refuge
    cast Censure
    cast Strike of Judgment
    Bolt of Radiance is instant cast, 8 second CD; sovereignty is instant cast, 20 second CD; precept of refuge is instant cast, 5 second CD; censure is instant cast, 6 second CD; strike of judgment is instant cast, no cooldown. Also, precept of refuge has a buff that lasts for 8 seconds, and censure has a debuff that lasts for 15 seconds.

    As you can see, this macro is very much not organized via cooldowns, so why is it organized the way it is? Simple, optimization. Clerics have a GCD of 1.5, and all these skills are instant cast, so it's easy to show that no cooldown limitations will occur (1.5x5 = 7.5 < 8, 1.5x4 = 6 < 20, 1.5x3 = 4.5 < 5, 1.5x2 = 3 < 6). Bolt of Radiance is obviously first as a threat generator (forces mob to attack for 3s), Sovereignty is most likely placed second due to its range and additional threat from damage, Precept of Refuge carries an important shield buff, and Censure/Strike of Judgment bring up the rear with an unimportant debuff and damage.

    So what does the execution look like? That's easy enough to analyze:
    Code:
    BoR,SoV,PoR,Cen,SoJ,SoJ,BoR,PoR,Cen,SoJ,SoJ,PoR,BoR,Cen,SoJ,SoV,PoR,Cen,BoR,.....
    So looking at that in terms of the PoR buff:
    PoR buff (lasts 8 seconds): 7.5 seconds until refreshed, 6 seconds until refreshed, 7.5 seconds until refreshed

    So the 15% block buff never dropped off us in the above execution. That could mean the difference between living and dieing. People tend to believe that simply throwing skills into macros and spamming the buttons is the way to go, but a more careful analytical approach usually leads to a better macro.

    Tips
    In this section I'll outline some basic tips for making functional macros. Nothing extraordinary, and after reading the above sections most of these are probably obvious:
    1. Put proc skills at the top of the macro. Yes, you can technically put them at the bottom (you'll activate them during the GCD on normal skills), but it requires you to spam the macro button extremely fast, especially for rogues.

    2. You can have more than one instant-cast no-cooldown skill in a macro as long as there are instances in which all but one are invalid. For example, many Champ/Paras have their main spam macro setup like this:
      Code:
      #show blahblahblah
      suppressmacrofailures
      .......
      cast Power Strike
      cast Path of the Wind
      Path of the Wind and Power Strike are both instant-cast no-cooldown skills (though this will change in 1.1), but Power Strike can only be used in melee range. This means that as long as you aren't in melee range Path of the Wind will be used, otherwise Power Strike will be used.

    3. Use modifiers sparingly. Many times people will forget they have modifiers in a macro and the associated skill will go unused. Also using a modifier with multiple skills in a macro is uncomfortable, as you have to hold down either shift/alt/ctrl (whichever you used) and spam a macro key. I generally tend to use modifiers only for high-cooldown situational skills that fit the theme of that macro.

    4. Don't be afraid to macro only one skill (like with mouseover macros) or to macro a whole lot of skills. As long as the skills used in the macro make sense, function properly, and aren't skills you need to activate on the fly (like "oh shi-" skills) it probably won't cause any issues. If it does, just change the macro.

    5. Finally, macros are supposed to make life easier. If you find it making it harder, reconsider using a macro for whatever you're trying. Not everything feels "natural" when macro'd.

    References[list][*]Commands List: A great reference for the various commands and emotes in RIFT. The most structured guide I have found, and it includes examples that show not only how to use the command, but what it will do. A must-bookmark for any serious macro maker.

    --------------------

    As a final note, I'd like to thank Trion for bringing us such a great game along with all the bug fixes and new content that they managed to churn out so fast. I'd like to thank the community for the initial macro information that got me started, and I'd like to give a special thanks to the section of the community who dedicate themselves to discovering new and interesting mechanics behind the game that we all love.

    If editing is allowed in the future, I'll try to keep this guide as up-to-date as possible along with any rewording that needs to be done in order to clarify any of the sections. If anyone wants to contribute real-world macro examples of anything presented in this guide, I'd love to have them associated with the guide, so feel free to post the macro. That'll ensure credit is given to the originator.

    Thank you for reading, hope it helped de-mystify macros for some people,
    Rin
    Last edited by Rinsho; 03-29-2011 at 06:43 PM.

  3. #3
    RIFT Guide Writer
    Join Date
    Mar 2011
    Posts
    27

    Default

    Stupid 5 minute edit limit
    EDIT:
    Quote Originally Posted by Rinsho
    References[list][*]Commands List: A great reference for the various commands and emotes in RIFT. The most structured guide I have found, and it includes examples that show not only how to use the command, but what it will do. A must-bookmark for any serious macro maker.
    References
    • Commands List: A great reference for the various commands and emotes in RIFT. The most structured guide I have found, and it includes examples that show not only how to use the command, but what it will do. A must-bookmark for any serious macro maker.
    Last edited by Rinsho; 03-29-2011 at 06:50 PM.

  4. #4
    Telaran sushicide's Avatar
    Join Date
    Dec 2010
    Posts
    91

    Default

    bump for nice info

  5. #5
    Rift Disciple Ghartan's Avatar
    Join Date
    Jan 2011
    Posts
    121

    Default

    I still like this post the bestest for macro explanation

  6. #6
    Rift Disciple Volfin's Avatar
    Join Date
    Feb 2011
    Location
    Cali
    Posts
    143

    Default

    I don't even see how this is useful considering you can't chain casts. it's not a macro by the real-world definition.

  7. #7
    Shield of Telara MaddBomber83's Avatar
    Join Date
    Jan 2011
    Location
    West Texas, USA
    Posts
    706

    Default

    Hey;

    Wanted to share something on macro structure.

    The macro system only looks at the first #show SkillName.

    You can use this to your advantage by using additional #show (whatever you want) to add labels or notes to your macro. As an example (made up ability names as I'm not at my RIFt comp)

    #show Ranged Spam
    suppressmacrofailures
    petattack
    #show (.........................Reactions)
    cast React on Block
    cast React on Parry
    #show (.........................Cooldowns)
    cast 15 sec cooldown
    cast 5 sec cooldown
    #show (.........................Melee Spam)
    cast Melee Spam
    #show (.........................Range Spam)
    cast Range Spam
    I add the (............ to make it stick farther out, easier to read.

    This makes it usefull when you have several characters and roles. When you get new abilities it is quick and easy to see where they should go when you start forgetting where to put everything.
    Last edited by MaddBomber83; 05-16-2011 at 03:42 PM.

+ Reply to Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts