Noticed my MQ2 autologin was getting stuck at the server select screen after making this change. I made the following change to my MQ2AutoLogin config file:

Code:

;ez=[] EZ Server - Custom Zones, Vendors, Quests, Items, etc
ez=EZ Server - Custom Zones Vendors Quests Items etc

I think this is because we're not listed under the gold (Legends?) servers currently. You can find out what the server name is from the eqlsPlayerData file:

Code:

LastServerName=EZ Server - Custom Zones Vendors Quests Items etc

Thank you Sanjii, this worked for me.  Make sure you enter the server name as Sanjii listed, omit the commas

Updated the line to use the ctrl key with pickup up the heroic resist aug so it should not require you to hold the key manually.  I don't know how I feel about further automating the process by filling multiple magic boxes etc as it already addresses the tedium in the click drop requirement.

I was refactoring a more elegant solution but if it just needs ctrl key for now, that's an easy add

Sounds like a great way to test it! If I can hop on I'll look for you.

It is easily doable, just requires a few additional considerations. The logic is already there it just needs to be modified. If I have some time this weekend I will look into it.

The intent if the aug was definitely not to increase tankability of non tank classes but survivability. Just put a condition check on the buff, each pulse check if the character has agro...if buff is up and character has agro set duration to -1 and the buff fades.

As far as guardian charm, it was a broken effect on purpose.  Once you got the first ultimate charm it worked as intended. The problem was during dev transition, much like the cleric self vie buff, it was reported as broken and incorrectly enabled without addressing why it was never intended to work or be used that way in the first place.

http://ezserver.online/forums/index.php?topic=5600.msg70868#msg70868

I made a macro to help in setting the appropriate in game filters, this allows you to save filter sets and load sets on the fly without having to spend time clicking dop downs on the options screen.

I had a discussion with Akka once where he clarified in game filters being the best thing to control the rate of incoming information for the client to process as each running instance will parse each packet and this will limit the packets.

Combine in game filters and mq2 filters and you shouldn't have issues in any zone.

Dimur - Thanks for all the work you have put into this and I hope that I am not over stepping trying to help out.  The current one with the variable delay has some broken code lines so the delay is not functioning right.  Line 439/470 are missing } at "${EZLootIni" - I ended up getting a friend to help me look at finding the problem.  The delay on line 85 is also being ignored due to the ${Window[LootWnd].Open} after it and that was a cause to part of the problems I ran into.

Thanks Rangewind for isolating the curly brackets issues, I've updated the linked file to correct this. 

Regarding line 85, the $(Window[LootWnd].Open} after the delay is a condition check, it tells MQ2 /delay for 2 seconds UNLESS loot window is open, basically says wait up to 2 seconds for the loot window to be open to proceed, if loot window is open before the delay it just moves on.

The macro evaluates the item on the corpse as a string, if it finds a matching string in the INI it checks the setting for the item and does the appropriate action, Keep means it gets looted etc.  MQ2 has limited options by default for collection objects, you can do an array or a string with a delineator between items on the string.  The macro tallies up the corpses in range, for each corpse it finds it adds it to the end of the current string by adding a comma and the corpse ID.  When it starts looting it reads the string by evaluating each corpse id, by default when MQ2 reads a string the comma is the delineator.  When MQ2 sees the 20,000 or 50,000 as the item name, it reads 20 then stops or 50 then stops because it assumes the comma means end of line (delineator).

There are a few ways around this, you can hardcode the item ID into line 95 as an additional check using an OR condition with the || which would probably be the easiest or your could write a small sub routine to check for 2 strings with the second string being 000 to identify the AA crystals, this would work until another item ends up having ,000 in it's listed name.  If someone wants to inspect the items and give the ID numbers for them, I can add that line of code as a quick fix for now.

I can look at refactoring this soon, I may have the link set to the wrong file.  The comma is the default delineator so you can't use the string to compare, an easy fix would just add an or check for both, I have just been lazy.

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.

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.

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

Hello!

This is a great macro, but I have been having trouble getting it to work at its potential. The main problem i am having is that it will loot a corpse much too fast and end up skipping over an item it was supposed to loot on that corpse. For example, this happens on average once or twice per wisp clear in jaggedpine to give an idea about frequency. My solution has been to /hidecorpse none and re-EZloot and everything usually gets picked up the 2nd time around.  Additionally, i can not get the Announce function to work properly.

I downloaded the 3 files in the first post, as well as the pre-populated loot ini. Since i discovered these issues, i have deleted and re-downloaded everything from scratch and experience the same problems. Does anyone have any ideas what could be amiss? I attached all the relevant files I am using in case that helps.

Thank you!

It's likely the macro is running faster than EQ can keep up with, the default setting for delay is .2 seconds and the macro doesn't know if EQ has completed one step before moving on to the next.  Instead of making the user have to go an modify each delay in the macro, I added the ability for a user to update the standard delay.  There should be a new setting in the updated EZLoot file for Standard Delay.  This will default to 2 (.2 seconds) but is user modifiable up to 50 (5 seconds), once you set the value to what you want it should stay at that value until you change it again.  

You can either change it in game:  /echo ezset 'Standard Delay' to 6 (for .6 second delay)
                   or directly in the ini: [Settings] Standard Delay=6

Give it a shot and let me know if this helps

Additionally, i can not get the Announce function to work properly.

I think the AnnounceString was disabled because people had issues crashing if they exceeded the max character count on a string, IE MQ2 has a limit to how many characters are in a string and if you loot enough items that the list of looted items exceeds it can crash.  I may revisit this and see if I can get a work around, I have a few ideas how to approach it.

My guess would be the client being unable to process incoming information fast enough.  I would start by turning off all in game filters then use MQ2 to filter the rest.

I have not found anything in the code, it should check the directory for the ini file...if found it should update and if not it generate a new one.  I don't see anything that would prevent it from updating an existing ini file.  Are the offending char ini files set to read only?