So, this particular BuffBot2, as all the other updates ...still remains a buff line for 71+ toons and not for the lower levels. So, if you want a Buff Bot macro that still takes care of lower levels, the Guild Buff Assistant is still the way to go. However, that Guild Buff Assistant is still in need of work in order to include the last 2 expansion buff lines. I have been working on those myself, ...where would I put those updates or who should I send those updates to? (I mean updates for Guild Buff Assistant (/mac Buffbot)
-
You've discovered RedGuides, an EverQuest multi-boxing and scripting community 🧙♀️⚙️. We want you to play several EQ characters at once, come join us and say hello! 👋
Resource icon
- Thread starter MacQ
- Start date
You are incorrect. I have successfully tested and operated BuffBot2, using version 1.3 and the current INI format, with low level spells (spells well below 71 even level 1-10 spells) and low level characters (below level 10). You have not configured the INI correctly.
If you disagree, post your INI here for review.
Last edited:
Hey, I am not one to cause trouble, I will relook at it again and if I have any questions ...I will get back to you. For now, I stand corrected.
My release contains all appropriate files.
To simplify the macro through the reduction of dependencies, I incorporated my personal version of Cast (MQ2Cast2.inc) into my macro and removed the #include mq2cast2.inc. My release notes for version 1.3 state MQ2Cast2.inc is no longer needed. Here is an exact quote from the 1.3 release notes (sixth bullet point from the top) that I posted under Update(s).
- The macro no longer requires any include files like MQ2Cast2.inc, but it still requires the MQ2Cast plugin.
Last edited:
There is a very simple approach ... post your INI so I can review it. That is how I can determine if there is a problem with my macro or a problem in the INI.
Xunil
Member
- Joined
- Mar 8, 2021
- RedCents
- 61¢
The say, I was concerned get reported, it shows obvious botting, though I do restrict mine to guild hall.
I went in and made it go to tells. I also made it tell the requestor as it does each buff and if the buff doesnt work (which seems to be almost always it wasnt ready, ie Regrowth on shamans) I tell the user, buff was most likely not ready.
This works for my shaman, I understand the druid issue, maybe, if count of buffs is larger than 4, put 2 spells on each line, larger than 6, put 3 spells per line? This would lessen the tells and not need a delay entered into the fray.
Another nicety would be if this would work during groupings. I have people that know my shaman and will ask him during a group outing. I know I could just turn it on, but he may or may not have those spells memmed, so he would need to record, say, last gem slot, replace it, buff, replace, buff, replace, buff, then put it back to what it was. This part goes beyond my knowledge of variables atm. If he somehow worked well with mq2Shaman, ie, pause shm, buff user, resume shm.
I could probably figure out the pause resume as mq2Shaman has easy /shm pause true /shm pause false.
I understand this is probably way beyond the scope of what you were attempting. I really like this, and code was easy for me to go through for my first time at scripting like this.
Thanks!
I went in and made it go to tells. I also made it tell the requestor as it does each buff and if the buff doesnt work (which seems to be almost always it wasnt ready, ie Regrowth on shamans) I tell the user, buff was most likely not ready.
This works for my shaman, I understand the druid issue, maybe, if count of buffs is larger than 4, put 2 spells on each line, larger than 6, put 3 spells per line? This would lessen the tells and not need a delay entered into the fray.
Another nicety would be if this would work during groupings. I have people that know my shaman and will ask him during a group outing. I know I could just turn it on, but he may or may not have those spells memmed, so he would need to record, say, last gem slot, replace it, buff, replace, buff, replace, buff, then put it back to what it was. This part goes beyond my knowledge of variables atm. If he somehow worked well with mq2Shaman, ie, pause shm, buff user, resume shm.
I could probably figure out the pause resume as mq2Shaman has easy /shm pause true /shm pause false.
I understand this is probably way beyond the scope of what you were attempting. I really like this, and code was easy for me to go through for my first time at scripting like this.
Thanks!
I was always unsure about the best way to communicate (/say vs /tell) which is why I added the flexibility in the INI for users to choose how they want BuffBot2 to communicate. I am glad you were able to set the INI communication options to suite your needs. You will quickly figure out the necessary delay between /tell lines, which I guess should be about 5-8 (tenths of a second).
I also considered having BuffBot2 speak (in /say or /tell depending on a variable in the INI) each buff it cast so the user isn't sitting there wondering if the BuffBot2 is broken because they are not smart enough to consider things like spell refresh timing, at least I did include a Reagent check. The fact that you added this change makes me think I should add some additional flexibility to the INI to allow users to choose if they want BuffBot2 to speak each buff and if BuffBot2 can't cast that buff, state the reason why. So in the next version I will add a few more settings to the INI to allow toggling this extra level of communication on/off.
One more item I may consider is adding a user definable INI delay variable for each spell that controls how long to wait until a spell becomes available. This is already incorporated into my Cast routine, but I need to be careful about adding too much flexibility (variables) to the INI because I run the risk of overwhelming BuffBot2 users with too many features/conditions they don't understand.
Thank you for the constructive feedback, it's very helpful.
Last edited:
MacQ updated BuffBot2 with a new update entry:
Version 1.4
If you discover any bugs or have suggestions, please post to this Discussion.
Version 1.4
Read the rest of this update entry...
If you discover any bugs or have suggestions, please post to this Discussion.
Last edited:
I have a question to anyone that is using Guild Buff Assistant and this other Macro BuffBot2 . Do you see any advantages to one over the other. I have not been in good health and have every intention of working on my resource Guild Buff Assistant if there is interest and people are still using it.
Hi Medicman, I know you have contributed much to the Redguides forums and I sincerely hope your health improves.
I /salute you sir.
Last edited:
dontrootmebro
Well-known member
- Joined
- Sep 28, 2018
- RedCents
- 1,271¢
I am still using BuffBot1. I have not tried BuffBot2 or Guild Buff Assistant yet. I have just updated spells and tweaked it myself.
Kyle, thank you for pointing this out. I guess there are some PCs who might make a buff request then run away before the buff cycle is finished.
To deal with the issue, I added a new routine to check for LOS (line of sight) for each buff in a buff cycle. I am testing the routine in a beta version and if all goes well, I expect to release an updated version (1.7) early next week.
Thanks again for your post. This is the kind of good feedback that helps improve the program.
This is a great macro, the only a few things that are holding me back from switching from buff bot 1.
1. Hail starts buffing.
2. Allow list of toons- I have a lot more people I want to Deny than Allow. (not a game stopper)
3. Allowing multiple guilds since I have my team spread across a few guilds.
Do you have any suggestions on how I can modify the macro to do these things?
1. Hail starts buffing.
2. Allow list of toons- I have a lot more people I want to Deny than Allow. (not a game stopper)
3. Allowing multiple guilds since I have my team spread across a few guilds.
Do you have any suggestions on how I can modify the macro to do these things?
Thank you for the compliment. Let me think about this, here are a few initial thoughts.
1) If I set to buff on hail, then that would eliminate the message to the user telling them about commands like buff, rez, summon, items, and list. They would not know to say list to get a list of commands, which is important for the Druid with all its ports. This also interferes with other commands like telling a mage to cast items versus buff. If you hail the Mage, are you going to get all the buffs and all the items, I think people would not like that. What about the Cleric and Necro who also have commands like summon and rez, again, if you hail them, they will start buffing and the user will have no idea about those class specific commands like summon and rez. I realize a hail is very simple, but the feedback I've received is that sending a command via /tell is not horribly cumbersome.
2) I like the idea, but if I create a Deny list then you can't have an Allow list, they would conflict, it would be one or the other. But the idea is doable and I have an idea how to make it work. I could create a variable to add PC names, then have a toggle to set the list to either Allow or Deny.
3) I like this idea too and could create a variable for users to add a list of guilds, but here is the rub, configuring this takes some "basic logic sense" from the end-user. For example, let's say someone creates a list of guilds AND an Allow/Deny list and says the program is all screwed up because they can't figure out the mess they created (i.e, they allowed a guild to be buffed but a PC in the guild is on the Deny list and can't get buffed). Well the program won't be screwed up, it's the end-user who would have created a logic conflict in their brain because they understand precedence. Decades ago I developed some software that managed security access for a file system that included group security and individual security settings. In most systems, an individual (allow/deny) list would take precedence over group permissions. In this case the "group" is the guild. Anyway, I think I can implement this.
Last edited:
We have been running the older BuffBot for a few years now, but I am interested in testing this out. Downloaded and attempted to start on an enchanter, it immediately kills the EQ instance. I don't see any crash dumps or other diagnostic info. Any ideas?
Thank you for your post.
I do have a thought, in the INI, change BuffZoneCheck to FALSE. This condition, however, is logged in the BuffBot2 log file (in your MQ log folder), there will be an entry if this is happening.
In the latest release, I did not properly set the above variable in the sample INI (included in the release) to FALSE.
I realize this reaction to a zone check seems harsh for being in the wrong zone, but these settings are all user configurable in the INI file.
This is from the Instructions page of this macro:
- BuffZoneCheck = [TRUE or FALSE] to limit the macro’s operation to a zone listed in BuffZoneShortNames. Default in the sample INI is FALSE.
- BuffZoneShortNames = use the short name of the zone(s) you want to allow the macro to operate, separating each short-zone-name with a comma.
- BuffZoneNotEqualAction = If you enable BuffZoneCheck and your bot is not in one of the listed zones, this is the command you want to execute (e.g., /end, /q, /echo, whatever you want).
P.S. There is one bug I know about ... if the buff recipient moves out of sight (LOS), there is a typo in the macro where it incorrectly calls a sub PCTell which should be PCChat and that causes the macro to crash. This bug is fixed in the upcoming version 1.8 due out in about a week.
Last edited:
Cool, got that working.
Now I am building the ini for the the spells we want, and I have run into some issues:
- I would really like it if the buffer would just start the buff routine upon hail, is that possible?
- I started with the Shaman buffs for 1 - 45 level toons:
- Harnessing of Spirit -gem1
- Chloroplast -gem2
- Spirit of Bih`Li -gem9
- Talisman of Celerity - alt 2049 (11th spell)
- Shaman will cast the first 2, but not the last two when a level 5 toon hails
- Shaman will do nothing with a level 120
MacQ updated BuffBot2 with a new update entry:
Version 1.8 - Bug Fixes and Enhancements
Read the rest of this update entry...
Version 1.8 - Bug Fixes and Enhancements
Read the rest of this update entry...
Last edited:
In version 1.8 I added enhanced security (access) functionality to handle your #2 and #3.
sweet man thanks!
What do you have BuffZoneCheck set to [TRUE or FALSE}?
Thank you very much for the update and I'm glad you resolved the issue. There is a lot of flexibility in this macro, and it's all about the settings in the INI.
Check out the new version 1.8, it has some additional features to control access.
Thank you this fixed it.
Sorry I'm not certain what you mean, but you define the hail response text for each class. If someone hails you, the only response they see is what you defined in the respective [CLASS} section of the INI for HailResponse.
From the Instructions page:
- HailResponse = Each bot can have its own hail response. The only hard coded command for this entire macro is list, all the other commands you configure within the INI (i.e., in the SpellInternalKey# variable).
Last edited:
Odd, the current HailResponse is default, but chars will still list in say upon hail.
please do not post character names.
Try the default INI, make no changes, and see if you have the same issue.
If that does not fix it, post your INI here and I will review, but make sure you empty out the variables VerifyPCList and VerifyGuildList so you don't list any guild names or character names.
Also, what character classes are you using?
Would You or anyone else have an updated INI for buffbot2 . Ive tried editing and adding spells for the TOL but always seem to have some sort of issue. Any help would be GREATLY APPRECIATED.
Me too please! Whenever I update the ini for new spells it just casts the old spells.
- Joined
- Nov 10, 2021
- RedCents
- 220¢
anyone have a good Mage list already made out?. 1-120 for high and low level players?.