Understanding the macro logic flow

Dimur

Hero Member
Hero Member

Posts: 699

Understanding the macro logic flow

« on: March 28, 2021, 09:34:48 pm »

MQ2 macros are incredibly useful but the syntax isn't intuitive. A macro will only do what you tell it to do, but how do you tell the macro what to do? The first thing is to break everything down into small and manageable parts. What do you want MQ2 to do? Each step in the process should be it's own sub routine, this lets you refine one step at a time and not have to dig through lines of code to correct or update the macro.

Here's a simple breakdown of the EZLoot macro logic. This macro is a passive macro, it runs in the background until you tell it to do something, it watches for events. Events are a way to tell MQ2, 'If you see this, do this.' MQ2 will watch whatever chat window(s) you tell it and watch for the matching text, if it sees the text it does the corresponding sub routine. In the case of EZLoot, it watches for the echo command which is specific to the MQ2ChatWindow. If MQ2 sees /echo ezloot, it enters the sub routine for the event EZLootLogic. Here is the EZLootLogic macro broken down. It's not the actual code but you can pull up the EZLoot.inc file in your Macros folder to see the actual code, this is more a representation of what that code does.

Event_EZLootLogic
--
[ LOOT LOGIC ]
1. /alias /setto /echo setto                      (updates MQ2 alias command for ease of use for user)
2. /call SetUpOuterVariables - RETURN                (sets up the variables used in macro)
3. /if FirstRun==0 /call RunMessage - RETURN          (on first run display message)
4. call BuildIni                              (loads ini if it exists, builds new one if it doesn't)
/call InitialSettingsValues                     (set default initial values for variables)
/call UpdateVariableValuesToIniSettings - RETURN   (update variable values to values in ini)
5. /if ${SpawnCount[corpse radius ${LootRadius}]}>0)    (if there are greater than 0 corpses nearby)
{
      /say #corpsefix                           (fix any bugged corpses)
      /bc Calling LootLogic
      /call LootLogic                           (call the LootLogic sub routine)
      -- /call TallyCorpses - RETURN               (tally corpses, put them into a string to iterate through)
      -- /call LootCorpses - RETURN (check corpse, evaluate each item and take corresponding action)
      -- /call CheckForMissedCorpses - RETURN         (if any corpses were not added to initial list, create new list, loot)
      -- /call AboutToExit - RETURN               (if LootAnnounce turned on, summarize what was looted)
   } else {
      -- /doevents (no corpses found, continue listening for instructions)
   } - RETURN

Make sense so far?
1. The first thing it does is make an alias command called /setto, this makes it so that you can update items to your INI file by just holding them on cursor and typing /setto. An alias in MQ2 is a shortcut for a line of code, it's very handy to make easy to type commands for longer lines of code than is feasible. In this case, typing /setto will execute the command [/echo setto] which is another event for EZLoot to watch for.

2. The next thing it does is calls a sub routine to set up the variables that will be used in the macro. Variables are a dynamic way to set the values you want to memory so you can continue to access them. Variables are beyond the scope of this post and an integral part of any programming language.

3. The macro looks to see if this is the first time it has been run, if so it shows a help message to explain how to use this macro.

4. The macro looks for an ini for this character, if one exists it continues, if no ini exists for this character the macro builds a new one.
- Default values for the variables are set, this is required if there was no existing ini and the defaults will be put in the new ini.
- If there was an existing ini file, it loads the corresponding values into the variables.

5. The macro checks for corpses nearby, the distance it checks is set in the ini and can be updated by the user
- At least one corpse found? Use the corpsefix command to fix any potentially bugged corpses, call the sub routine LootLogic
- LootLogic starts by tallying corpses and putting them into a list by corpse ID, then it starts looting corpses one at a time
- When it's looted the last corpse in the list, it looks again for any nearby corpses, if any are found it loots them, if not it goes back to watching for commands
- If Announce is turned on, every item looted will be added to a list, once all corpses are looted it announced what you looted that round


	Logged

Dimur

Hero Member
Hero Member

Posts: 699

Re: Understanding the macro logic flow

« Reply #1 on: March 28, 2021, 09:47:02 pm »

That is basically the logic flow for the macro, now we can start breaking down the sub routines to make sense of them.

The first sub routine called by this macro is SetUpOuterVariables

Looking at this code appears daunting at first because there are so many variables we are using. But if you just look line by line it makes a bit more sense.

/if (!${Defined[ezd]}) /declare ezd int 2

This tells MQ2, IF there is NOT a variable called ezd to DECLARE (create) that variable, make it a whole number (integer) and set the value for it to 2.

ezd is the variable name for the delay between commands for this macro. You have to have a bit of delay between commands to let EQ execute the command that MQ2 tells it to before going to the next line. MQ2 sends the commands to EQ and EQ performs them so this default delay is user adjustable and should be set as low as you can as long as you aren't encountering errors like corpse slot items being skipped because by the time EQ is ready for the next command MQ2 is looking at the next corpse slot.

All of these variables are used in this macro and they can be updated while the macro runs. The only thing this sub routine does is checks for the required variables and declares them if they don't exist, populating variables with default values that can later be updated to the values listed in the ini.


	Logged

Dimur

Hero Member
Hero Member

Posts: 699

Re: Understanding the macro logic flow

« Reply #2 on: March 28, 2021, 10:09:13 pm »

Next up is the BuildIni sub routine, it could just as easily be named CheckForIni. Looking now, the first called sub routine is SetUpOuterVariables which is probably redundant at this point since we just ran it, this is probably a line that can be removed, but it really doesn't hurt to run it again because it will just verify that all the required variables are available for the macro to use. Here are the things this sub routine does:

1. calls SetUpOuterVariables

2. IF the variable EZLootIni exists (this is set as EZLoot_CHARNAME, so for me it looks for EZLoot_Dimurwar in the macros folder) it tells the user that it is loading the ini
ELSE
- set a variable to hold the values needed to create the new ini file
- tell the user there was no ini found for this character and one is being created
- iterate through all values in the variable we made that we needed to create the new ini file
- check to make sure the file was created, if not ask user to report for fix review
- if successful, tell the user the file was created

3 Call the sub routine InitialSettingsValues - here we jump out of our current sub routine and enter the called one

The sub routine InitialSettingsValues looks to see if the Settings have values from the ini to use, if there is not an existing value for a Setting then a default one is applied
- Once this sub routine has finished, it calls a new sub routine name UpdateVariableValuesToIniSettings

This called sub routine just sets some specific variable values to the ones listed in the ini then it returns to the calling sub routine, InitialSettingsValues and goes to the next line in that sub routine which is just a RETURN statement, return means to go back to the calling sub routine, and in this case that puts us back in the sub routine BuildIni which also has a RETURN statement as the next line, this returns us to Event_EZLootLogic and the line after the call to BuildIni.


	Logged

Pages: [1]

« previous next »

�

User

EZ Server Tools

EZ Server Downloads

Useful Links

Search

Recent

Stats

Members

Stats

Users Online