Dev's Bot - a potential problem.

[aspire2008]

Chatswiththisname, finally got some time to start going through and pulling out undefined variables for you:


Warriorbot.mac (may not be exclusive to this mac file and may apply to all bots)

- [2017/12/14 05:40:40] WARNING: Undefined Variable aggroCheckTimerStr used on line 562@warriorbot.mac /call EchoLog ".....GROUPROLE: ${groupRole} MAINASSIST: ${mainAssist} MAINTANK: ${mainTank} ASSISTPCT: ${assistPct} AGGROCHECKTIMER: ${aggroCheckTimerStr}" TRUEMacro Paused.

-------

- [2017/12/14 05:47:08] devCommonPremium.inc@2075 (buffCheckRoutine(string checkTypes, bool combatBuff, string onCallRoutine)): /if (${Me.Aura[1].Equal[${buffText[${nArray}]}]} || ${Me.Aura[1].Equal[${buffName[${nArray}]}]} || ${Me.Aura[2].Equal[${buffText[${nArray}]}]} || ${Me.Aura[2].Equal[${buffName[${nArray}]}]}) {
- [2017/12/14 05:47:08] devCommonPremium.inc@1711 (buffCheck(bool useTimer, bool combatBuff, string onCallRoutine)): /call buffCheckRoutine ${checkTypes} ${combatBuff} ${onCallRoutine}
- [2017/12/14 05:47:08] warriorbot.mac@107 (main(string iniNameStr, string groupRoleStr)): /if (!${minBuffCheckTimer}) /call buffCheck
- [2017/12/14 05:47:08] No such 'auratype' member 'Equal'

*******************

Bardbot.mac (may not be exclusive to this mac file and may apply to all bots)

- [2017/12/14 06:12:57] WARNING: Undefined Variable castWhileInivis used on line 381@bardbot.mac /if (!${castWhileInivis} && ${Me.Invis}) /return ABORT_INVISMacro Paused.

------

- [2017/12/17 19:09:50] WARNING: Undefined Variable combatGem used on line 468@bardbot.mac } else /if ((${combatSong${twistPos}.NotEqual[NULL]} || ${combatGem${twistPos}}) && !${twistTimer} && !${Me.GemTimer[${combatGem[${twistPos}]}]}) {Macro Paused.

---------

- [2017/12/14 06:12:57] No such 'string' member 'Name'
- [2017/12/14 06:12:57] bardbot.mac@197 (main(string iniNameStr)): /if (${Me.Aura[1].Name.Equal[${auraSong}]} || ${Me.Aura[2].Name.Equal[${auraSong}]} || ${Me.Aura[1].Name.Equal[${auraText}]} || ${Me.Aura[2].Name.Equal[${auraText}]}) {

-------

Not sure what this is but keeps getting spammed in the mq2chatwindow:

- [2017/12/14 06:19:55] Usage: /call subroutine<subroutine> [param [param...]]

------


This is also being spammed:

- [2017/12/14 06:20:05] [MQ2] [MQ2] >> Checking XTarget for adds
- [2017/12/14 06:20:05] [MQ2] [MQ2] >> CheckForAdds completed.  newAddID: ${newAddID
- [2017/12/14 06:20:05] [MQ2] [MQ2] >> Checking XTarget for adds
- [2017/12/14 06:20:05] [MQ2] [MQ2] >> CheckForAdds completed.  newAddID: ${newAddID
- [2017/12/14 06:20:05] [MQ2] [MQ2] >> Checking XTarget for adds
- [2017/12/14 06:20:05] [MQ2] [MQ2] >> CheckForAdds completed.  newAddID: ${newAddID
- [2017/12/14 06:20:05] [MQ2] [MQ2] >> Checking XTarget for adds
- [2017/12/14 06:20:05] [MQ2] [MQ2] >> CheckForAdds completed.  newAddID: ${newAddID

******************


Wizardbot.mac </subroutine><subroutine>(may not be exclusive to this mac file and may apply to all bots)

- [2017/12/14 07:27:43] WARNING: Undefined Variable commandFrom used on line 4177@devCommonPremium.inc /if (${Bool[${Ini[${ININame},${INISection},${INIKey}]}]}) {Macro Paused.

---------

- [2017/12/14 07:34:22] WARNING: Undefined Variable harvestTimer2 used on line 304@wizardbot.mac /if (${harvestSpells[${hArray}].NotEqual[NULL]} && !${harvestTimer${hArray}}) {Macro Paused.

--------
Shamanbot.mac

Downloaded the version posted in this thread, When I run the macro I get:

 couldn't open include file: C:\Macroquest2\Macros\shamanBotSettings.ini

</subroutine>
<subroutine>

I tried to start the macro by doing /mac shamanbot ini_name




***************
Also, the change you made to mq2nav, it keeps defaulting the UseNavigation=FALSE setting in the ini files to TRUE, even when they were set to false. This is rather annoying when you aren't trying to use mq2nav to pull, and trying to use his pull path or radius pulling method instead.

I still stand by it just seems like this is an insurmountable task to go through 16 class macro files when bot.mac probably does about 80% of what dev's bots do (never used bot.mac so not really sure, but from what i read on the forums seems like it does about 75-80% of what dev's does). If you strip the pull code from dev's bots and incorporate all 3 pull methods into bot.mac it just seems like a less time consuming task.

Also, I'm sure there are more undeclared variables in the 3 macros I just sifted through, but won't know till these are probably fixed, so it spits out more undeclared variables, since its stuck in a loop.
</subroutine>

 

[devestator]

Hey Chat, it's awesome that you are putting some time into trying to get things running. Yeah, I went MIA shortly after the updates because I got rather annoyed that I spent like 10 hours fixing things as quickly as I could only to have MQ2 change and rebreak stuff again after I had already fixed it meaning I'd have had to duplicate my work and then some. I simply can't afford to keep dedicating that much time at once to fixing things that are broken multiple times by MQ2 changes.

I will say, if there are a lot of undefined variables that is peculiar and makes me wonder if it's not simply a problem with the loading function not creating the undefined variables as it should be doing. I rarely use an undefined variable simply because in most languages I work in I can't use undefined variables lol. So it mostly doesn't occur to me to even try doing that in macros. That said, with some of the changes to the way the function parameters were done, they are done in a way very different from normal programming languages now, so that to could be causing some issues. For example, I saw in one post someone mention something about a undefined variable warning on a line with an if that checked if it was defined, and then also used the variable in the same if. That is 100% valid programming logic in any other language lol. Other languages would never even parse the following conditions in an if, if the first condition failed and it was an AND not an OR logic. So I disagree with the way the parser in MQ2 is handling things like this now. It's taking a step away from standard programming design from the sounds of it.

All that said, I do agree with Aspire, the bots are bloated, and some of the code in them is pretty old. There are lots of things that should have been done differently if they were taken into account when initially creating the bot. It's just so many things got added as the bots grew and things became quite bloated. Debuffs for example, as you were dealing with them in one of your posts, that was a routine that was added after the initial creation of the core of the bots because the first couple of classes that were created didn't really have debuffs (at the time at least). It worked fine initially, but as more and more stuff was added, and EQ fights got faster and damage and such became more severe, it started to be inadequate.

Then other things grew to the point where they weren't so class specific anymore, like healing routines. There really should be one central healing routine these days. Initially only cleric had a healing routine and druid had some very basic healing behavior. But as EQ expanded Cleric, Druid, and Shamans all became viable healers. Even Rangers and Paladins can benefit from actually using their healing these days. There are lots of things like this that became so universal to multiple or all classes that it barely even makes sense to have specific class bots anymore. There are still a few cases where specific class bots can be a benefit, like bards since they are completely unique, and enchanters because of their specialization in mezzing and such. Pulling is one of those things that became universal and so the devPull routines is pretty robust for all classes. It was one of the last major rewrites I did in the bots and took into account requests and changes over the years of working on the bots.

There is probably plenty in the bots someone new can learn from, but there is also plenty that I probably wouldn't want someone new getting into the bad habit of lol. Getting the pull routines into another macro probably wouldn't be too difficult since the pull routines are mostly modular. There is devPull.inc that contains the bulk of the pulling routines. I think the only thing the routine needs that is not in that file is the movement routines from devMovementPremium.inc. It might also use devCast.inc for casting spells on a pull as I moved away from MQ2Cast a while back in favor of my own version of macro based casting like the old spell_routines.inc.

If you continue to work on them and have a question about something you can't figure out, feel free to email me at devestatorcoder@gmail.com and when I get free time I'll try to respond and help you out. Otherwise, perhaps when I finish this side contract I've been working on the past few months (should be finished sometime in January), if things are still having issues and there are still people who want them I can take a look again at that time. But, I think what MQ2 class automation really needs is a strong well written Plugin based bot. It would be faster and have more capabilities than a macro based one. Perhaps one that even has some machine learning built into it Would be a fun project for any programmers out there learning AI lol.

 

[Chatwiththisname]

Hey Chat, it's awesome that you are putting some time into trying to get things running. Yeah, I went MIA shortly after the updates because I got rather annoyed that I spent like 10 hours fixing things as quickly as I could only to have MQ2 change and rebreak stuff again after I had already fixed it meaning I'd have had to duplicate my work and then some. I simply can't afford to keep dedicating that much time at once to fixing things that are broken multiple times by MQ2 changes.

I will say, if there are a lot of undefined variables that is peculiar and makes me wonder if it's not simply a problem with the loading function not creating the undefined variables as it should be doing. I rarely use an undefined variable simply because in most languages I work in I can't use undefined variables lol. So it mostly doesn't occur to me to even try doing that in macros. That said, with some of the changes to the way the function parameters were done, they are done in a way very different from normal programming languages now, so that to could be causing some issues. For example, I saw in one post someone mention something about a undefined variable warning on a line with an if that checked if it was defined, and then also used the variable in the same if. That is 100% valid programming logic in any other language lol. Other languages would never even parse the following conditions in an if, if the first condition failed and it was an AND not an OR logic. So I disagree with the way the parser in MQ2 is handling things like this now. It's taking a step away from standard programming design from the sounds of it.

All that said, I do agree with Aspire, the bots are bloated, and some of the code in them is pretty old. There are lots of things that should have been done differently if they were taken into account when initially creating the bot. It's just so many things got added as the bots grew and things became quite bloated. Debuffs for example, as you were dealing with them in one of your posts, that was a routine that was added after the initial creation of the core of the bots because the first couple of classes that were created didn't really have debuffs (at the time at least). It worked fine initially, but as more and more stuff was added, and EQ fights got faster and damage and such became more severe, it started to be inadequate.

Then other things grew to the point where they weren't so class specific anymore, like healing routines. There really should be one central healing routine these days. Initially only cleric had a healing routine and druid had some very basic healing behavior. But as EQ expanded Cleric, Druid, and Shamans all became viable healers. Even Rangers and Paladins can benefit from actually using their healing these days. There are lots of things like this that became so universal to multiple or all classes that it barely even makes sense to have specific class bots anymore. There are still a few cases where specific class bots can be a benefit, like bards since they are completely unique, and enchanters because of their specialization in mezzing and such. Pulling is one of those things that became universal and so the devPull routines is pretty robust for all classes. It was one of the last major rewrites I did in the bots and took into account requests and changes over the years of working on the bots.

There is probably plenty in the bots someone new can learn from, but there is also plenty that I probably wouldn't want someone new getting into the bad habit of lol. Getting the pull routines into another macro probably wouldn't be too difficult since the pull routines are mostly modular. There is devPull.inc that contains the bulk of the pulling routines. I think the only thing the routine needs that is not in that file is the movement routines from devMovementPremium.inc. It might also use devCast.inc for casting spells on a pull as I moved away from MQ2Cast a while back in favor of my own version of macro based casting like the old spell_routines.inc.

If you continue to work on them and have a question about something you can't figure out, feel free to email me at devestatorcoder@gmail.com and when I get free time I'll try to respond and help you out. Otherwise, perhaps when I finish this side contract I've been working on the past few months (should be finished sometime in January), if things are still having issues and there are still people who want them I can take a look again at that time. But, I think what MQ2 class automation really needs is a strong well written Plugin based bot. It would be faster and have more capabilities than a macro based one. Perhaps one that even has some machine learning built into it Would be a fun project for any programmers out there learning AI lol.

Lots of useful information. I agree /if (${Defined[someVar]} && ${someVar} != 1) /dosomeshit; feels like it should work. But as EQMule mentioned in one of his posts at one time during some various updates from ages past, MQ2 parses the entire line, which means we as programmers cannot do what we feel -should- be okay.

Now it should end up looking like

/if (${Defined[someVar]}) {
/if (${someVar} != 1) /dothatthing
}

while this way wouldn't be considered wrong persay, it's not as efficient as it could be.

Actually had checked the loading routines a bit late in Bot40.mac as well, sad that I did wait so long as it turned out it had a flaw in it and after correcting it I reduced the amount of issues to nearly zero (comparatively). Since most of your macro's were modular I had hoped I could make corrections in the .inc working primarily with a single class which should use the routines that any class could end up using such as debuffs.

Most of my issue with the loading routines for some of these more advanced bots is that I don't understand the code enough to try to make changes without risk of breaking it. Alternately, I have tried and it didn't work thus reverted it to it's previous form.

If you do get a chance to check them out I'm sure it would likely be more efficient for yourself to check them as you are the creator. I'm just fumbling in the dark.

 

[Chatwiththisname]

It was presumptuous of me to assume everyone already had the default ini file for the shaman bot. My apologies. I downloaded all the files from Devastator's git and for some reason thought everyone else had done the same or had residual files from previous use.

 

[aspire2008]

I never used the default ini configuration when naming the file.

I always do "/mac shamanbot customname", when I first initiatlize the macro for the very first use, as well as every other time I start the macro.

 

[Chatwiththisname]

I never used the default ini configuration when naming the file.

I always do "/mac shamanbot customname", when I first initiatlize the macro for the very first use, as well as every other time I start the macro.

Going to load up the game and check this out for you.


As I can I'll go over the other things you mentioned. The aura issues shouldn't be horrible to fix. timers and such may be a bit more complicated for me.

Trying to bad the bad /call subs could be troublesome unless I can get a line reference. I'll get back to you when I know more.

 

[Chatwiththisname]

Custom file names seem to work okay for me.

Toon - [2017/12/24 13:40:44] "~~~~~~~~~~~~~~~~ChatWithThisName was Here~~~~~~~~~~~~~~~~~~~~~"
Toon - [2017/12/24 13:40:44] [MQ2] [MQ2] >> Initialized devCommonPremium.inc v3.53 - Written By Devestator - Updated by ChatWithThisName
Toon - [2017/12/24 13:40:44] [MQ2] [MQ2] >> Initializing devMovementPremium.inc v2.74 - Written By Devestator
Toon - [2017/12/24 13:40:44] [MQ2] [MQ2] >> Initializing devCast.inc v2.00
Toon - [2017/12/24 13:40:44] [MQ2] [MQ2] >> Loading Bot specific configuration...
Toon - [2017/12/24 13:40:44] shamanBotSettings_custom.ini is the name of INI.
Toon - [2017/12/24 13:40:44] "Pet settings complete!"
Toon - [2017/12/24 13:40:44] "Loading Heals Complete!"
Toon - [2017/12/24 13:40:44] [MQ2] [MQ2] >> Checking include file versions...
Toon - [2017/12/24 13:40:44] [MQ2] [MQ2] >> Common INI Load started, INI Name: shamanBotSettings_custom.ini
Toon - [2017/12/24 13:40:46] [MQ2] [MQ2] >> Using devCommonPremium.dat v1.02
Toon - [2017/12/24 13:40:46] [MQ2Nav] Invalid nav destination: 0 0 0
Toon - [2017/12/24 13:40:46] [MQ2Nav] No navigation path currently active
Toon - [2017/12/24 13:40:46] [MQ2] [MQ2] >> MQ2Navigation detected and set to be used, but you have no mesh for the current zone, not using MQ2Navigation
Toon - [2017/12/24 13:40:46] [MQ2] [MQ2] >> Initialized devLoot.inc v1.36 - Written by Devestator
Toon - [2017/12/24 13:40:46] [MQ2] [MQ2] >> devLoot.inc settings loaded from devLoot.ini
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Unable to load any pull paths, pulling will default to pulling without a path within the pull radius of 100.00
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> devPull.inc v1.10 loaded
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Creating ignore alert list number 101
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Creating safe pc alert list number 102
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> ShamanBot v2.26, written by Devestator, initiated
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Looting Corpses: FALSE
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Main Tank: NULL
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Main Assist: NULL
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Puller: NULL
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> INI FileName: shamanBotSettings_custom.ini
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Healing: TRUE
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Debuffing: TRUE
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Group Buffing: TRUE
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Minimum Check Time: 10s
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Self Buffing: TRUE
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Announcements: /g
Toon - [2017/12/24 13:41:04] The current macro has ended.
Toon - [2017/12/24 13:41:39] Your integrity has been preserved.

 

[Chatwiththisname]

Custom file names seem to work okay for me.

Toon - [2017/12/24 13:40:44] "~~~~~~~~~~~~~~~~ChatWithThisName was Here~~~~~~~~~~~~~~~~~~~~~"
Toon - [2017/12/24 13:40:44] [MQ2] [MQ2] >> Initialized devCommonPremium.inc v3.53 - Written By Devestator - Updated by ChatWithThisName
Toon - [2017/12/24 13:40:44] [MQ2] [MQ2] >> Initializing devMovementPremium.inc v2.74 - Written By Devestator
Toon - [2017/12/24 13:40:44] [MQ2] [MQ2] >> Initializing devCast.inc v2.00
Toon - [2017/12/24 13:40:44] [MQ2] [MQ2] >> Loading Bot specific configuration...
Toon - [2017/12/24 13:40:44] shamanBotSettings_custom.ini is the name of INI.
Toon - [2017/12/24 13:40:44] "Pet settings complete!"
Toon - [2017/12/24 13:40:44] "Loading Heals Complete!"
Toon - [2017/12/24 13:40:44] [MQ2] [MQ2] >> Checking include file versions...
Toon - [2017/12/24 13:40:44] [MQ2] [MQ2] >> Common INI Load started, INI Name: shamanBotSettings_custom.ini
Toon - [2017/12/24 13:40:46] [MQ2] [MQ2] >> Using devCommonPremium.dat v1.02
Toon - [2017/12/24 13:40:46] [MQ2Nav] Invalid nav destination: 0 0 0
Toon - [2017/12/24 13:40:46] [MQ2Nav] No navigation path currently active
Toon - [2017/12/24 13:40:46] [MQ2] [MQ2] >> MQ2Navigation detected and set to be used, but you have no mesh for the current zone, not using MQ2Navigation
Toon - [2017/12/24 13:40:46] [MQ2] [MQ2] >> Initialized devLoot.inc v1.36 - Written by Devestator
Toon - [2017/12/24 13:40:46] [MQ2] [MQ2] >> devLoot.inc settings loaded from devLoot.ini
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Unable to load any pull paths, pulling will default to pulling without a path within the pull radius of 100.00
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> devPull.inc v1.10 loaded
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Creating ignore alert list number 101
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Creating safe pc alert list number 102
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> ShamanBot v2.26, written by Devestator, initiated
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Looting Corpses: FALSE
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Main Tank: NULL
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Main Assist: NULL
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Puller: NULL
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> INI FileName: shamanBotSettings_custom.ini
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Healing: TRUE
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Debuffing: TRUE
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Group Buffing: TRUE
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Minimum Check Time: 10s
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Self Buffing: TRUE
Toon - [2017/12/24 13:40:47] [MQ2] [MQ2] >> Announcements: /g
Toon - [2017/12/24 13:41:04] The current macro has ended.
Toon - [2017/12/24 13:41:39] Your integrity has been preserved.

Bard issues. In which cases does it spam the /call issues and other things? Using default INI I load /mac bardbot and it loads through and sits. I could use a copy of the INI in my inbox. My bard is 93

Toon - [2017/12/24 13:53:50] "~~~~~~~~~~~~~~~~ChatWithThisName was Here~~~~~~~~~~~~~~~~~~~~~"
Toon - [2017/12/24 13:53:51] [MQ2] [MQ2] >> Initialized devCommonPremium.inc v3.53 - Written By Devestator - Updated by ChatWithThisName
Toon - [2017/12/24 13:53:51] [MQ2] [MQ2] >> Initializing devMovementPremium.inc v2.74 - Written By Devestator
Toon - [2017/12/24 13:53:51] [MQ2] [MQ2] >> Initializing devCast.inc v2.00
Toon - [2017/12/24 13:53:51] [MQ2] [MQ2] >> Loading Bot specific configuration...
Toon - [2017/12/24 13:53:51] [MQ2] [MQ2] >> Checking include file versions...
Toon - [2017/12/24 13:53:51] [MQ2] [MQ2] >> Common INI Load started, INI Name: bardBotSettings_.ini
Toon - [2017/12/24 13:53:52] [MQ2] [MQ2] >> Using devCommonPremium.dat v1.02
Toon - [2017/12/24 13:53:52] [MQ2Nav] Invalid nav destination: 0 0 0
Toon - [2017/12/24 13:53:53] [MQ2Nav] No navigation path currently active
Toon - [2017/12/24 13:53:53] [MQ2] [MQ2] >> MQ2Navigation detected and set to be used, but you have no mesh for the current zone, not using MQ2Navigation
Toon - [2017/12/24 13:53:53] [MQ2] [MQ2] >> Initialized devLoot.inc v1.36 - Written by Devestator
Toon - [2017/12/24 13:53:53] [MQ2] [MQ2] >> devLoot.inc settings loaded from devLoot.ini
Toon - [2017/12/24 13:53:53] [MQ2] [MQ2] >> Unable to load any pull paths, pulling will default to pulling without a path within the pull radius of 100.00
Toon - [2017/12/24 13:53:53] [MQ2] [MQ2] >> devPull.inc v1.10 loaded
Toon - [2017/12/24 13:53:53] [MQ2] [MQ2] >> Creating ignore alert list number 101
Toon - [2017/12/24 13:53:53] [MQ2] [MQ2] >> Creating safe pc alert list number 102
Toon - [2017/12/24 13:53:53] [MQ2] [MQ2] >> BardBot v1.29, written by Devestator, initiated
Toon - [2017/12/24 13:53:53] [MQ2] [MQ2] >> Looting Corpses: FALSE
Toon - [2017/12/24 13:53:53] [MQ2] [MQ2] >> Main Tank: NULL
Toon - [2017/12/24 13:53:53] [MQ2] [MQ2] >> Main Assist: NULL
Toon - [2017/12/24 13:53:53] [MQ2] [MQ2] >> Puller: NULL
Toon - [2017/12/24 13:53:53] [MQ2] [MQ2] >> INI FileName: bardBotSettings_.ini
Toon - [2017/12/24 13:53:53] [MQ2] [MQ2] >> Self Buffing: TRUE
Toon - [2017/12/24 13:53:54] [MQ2] [MQ2] >> Stay Behind: TRUE
Toon - [2017/12/24 13:53:54] [MQ2] [MQ2] >> Pulling: FALSE
Toon - [2017/12/24 13:54:15] [MQ2Nav] Loading waypoints for zone: poknowledge
Toon - [2017/12/24 13:54:55] [MQ2Nav] Successfully loaded mesh for poknowledge
Toon - [2017/12/24 13:54:55] MQ2MMOBugs :: You are now logged in as Chatwiththisname.
Toon - [2017/12/24 13:54:55] MQ2MMOBugs :: Your account status is now set to lifetime.
Toon - [2017/12/24 13:54:55] MezImmunes:|
Toon - [2017/12/24 13:54:55] Ignores:|
Toon - [2017/12/24 13:54:55] SnareImmunes:|
Toon - [2017/12/24 13:54:55] CharmImmunes:|
Toon - [2017/12/24 13:54:55] [MQ2] [MQ2] >> We have changed zones, setting home location to current location.

Note that I don't get into combat or anything like that when I run the macro's. Simply launch them to load completion and the end the macro once the character sits.

Decided to go ahead and fix aura spam and loading of default ini instead of bardBotSettings_.ini
Fixed the typo shown on line 381 on bardbot in your report.

/if (!${castWhileInvis} && ${Me.Invis}) /return ABORT_INVIS

where castWhileInvis was typoed to castWhileInivis <~To many I's

Fixed typo reported on line 468

!${Me.GemTimer[${combatGem${twistPos}}]} where it used to be !${Me.GemTimer[${combatGem[${twistPos}]}]}
^ I glanced at that and it seemed right to make that change...not sure though

wondering if - [2017/12/14 06:19:55] Usage: /call subroutine [param [param...]] is related to CheckForAdds spamming. Hopefully they are, because it would make it easier. More efforted will be required to track this one down.

/call CheckForAdds ${campRadius} ${Me.ID} false true is the ONLY call to CheckForAdds, which means this likely calls from an include which does other magic things that are hidden from the primary macro. Digging required.

Update: Changed the call to CheckForAdds to include the final parameter set to false as that's the intention according to the sub. Which lead me in reverse to check the calling sub is using all it's parameters, which was not the fact. Changed /call BardCombatCheck to include the only parameter /call BardCombatCheck True, which is the intention according to the code.

 

[aspire2008]

The custom file name problem was only with the shamanbot.mac you posted in this thread (pretty sure I used the the last .mac file posted), it worked fine for the other 3 bots since I got those of Github.

 

[Chatwiththisname]

Ok, updated the bardbot.mac file again. Hopefully sorts out those errors. Please check the download again.

 

[aspire2008]

Getting the following with the new version of bardbot you just posted:

[COLOR=Orange][2017/12/24 15:55:34] No such 'auratype' member 'Equal'
Toon - [2017/12/24 15:55:34] devCommonPremium.inc@2075 (buffCheckRoutine(string checkTypes, bool combatBuff, string onCallRoutine)): /if (${Me.Aura[1].Equal[${buffText[${nArray}]}]} || ${Me.Aura[1].Equal[${buffName[${nArray}]}]} || ${Me.Aura[2].Equal[${buffText[${nArray}]}]} || ${Me.Aura[2].Equal[${buffName[${nArray}]}]}) {
Toon - [2017/12/24 15:55:34] devCommonPremium.inc@1711 (buffCheck(bool useTimer, bool combatBuff, string onCallRoutine)): /call buffCheckRoutine ${checkTypes} ${combatBuff} ${onCallRoutine}
Toon - [2017/12/24 15:55:34] bardbot.mac@213 (main(string iniNameStr)): /if (!${minBuffCheckTimer}) /call buffCheck[/COLOR]
Toon - [2017/12/24 15:55:34] [MQ2] [MQ2] >> Buff check Completed
Toon - [2017/12/24 15:55:34] [MQ2] [MQ2] >> Checking XTarget for adds
Toon - [2017/12/24 15:55:34] [MQ2] [MQ2] >> CheckForAdds completed.  newAddID: ${newAddID
Toon - [2017/12/24 15:55:34] [MQ2] [MQ2] >> Checking XTarget for adds
Toon - [2017/12/24 15:55:34] [MQ2] [MQ2] >> CheckForAdds completed.  newAddID: ${newAddID

Toon - [2017/12/24 15:55:54] [MQ2] [MQ2] >> Checking XTarget for adds
Toon - [2017/12/24 15:55:54] [MQ2] [MQ2] >> CheckForAdds completed.  newAddID: ${newAddID
Toon - [2017/12/24 15:55:55] [MQ2] [MQ2] >> Checking XTarget for adds
Toon - [2017/12/24 15:55:55] [MQ2] [MQ2] >> CheckForAdds completed.  newAddID: ${newAddID
Toon - [2017/12/24 15:55:55] [MQ2] [MQ2] >> Checking XTarget for adds

Toon - [2017/12/24 15:55:55] [MQ2] [MQ2] >> CheckForAdds completed.  newAddID: ${newAddID
Toon - [2017/12/24 15:55:55] [MQ2] [MQ2] >> Checking XTarget for adds
Toon - [2017/12/24 15:55:55] [MQ2] [MQ2] >> CheckForAdds completed.  newAddID: ${newAddID

[COLOR=Yellow]TRUNCATED SPAM[/COLOR]
Toon - [2017/12/24 15:55:56] [MQ2] [MQ2] >> Checking XTarget for adds
Toon - [2017/12/24 15:55:56] [MQ2] [MQ2] >> CheckForAdds completed.  newAddID: ${newAddID
Toon - [2017/12/24 15:55:56] [MQ2] [MQ2] >> Checking XTarget for adds
Toon - [2017/12/24 15:55:56] [MQ2] [MQ2] >> CheckForAdds completed.  newAddID: ${newAddID
Toon - [2017/12/24 15:55:56] [MQ2] [MQ2] >> Checking XTarget for adds
Toon - [2017/12/24 15:55:56] [MQ2] [MQ2] >> CheckForAdds completed.  newAddID: ${newAddID
Toon - [2017/12/24 15:55:56] [MQ2] [MQ2] >> Checking XTarget for adds
Toon - [2017/12/24 15:55:56] [MQ2] [MQ2] >> CheckForAdds completed.  newAddID: ${newAddID
Toon - [2017/12/24 15:55:56] [MQ2] [MQ2] >> Checking XTarget for adds
Toon - [2017/12/24 15:55:56] [MQ2] [MQ2] >> CheckForAdds completed.  newAddID: ${newAddID


Toon - [2017/12/24 15:56:01] [MQ2] [MQ2] >> .....Action is set to continue
Toon - [COLOR=Orange][2017/12/24 15:56:01] WARNING: Undefined Variable singleMez used on line 857@bardbot.mac /if (${setTimer.Equal[NULL]}) /varset setTimer ${Spell[${singleMez}].Duration.Float}sMacro Paused.[/COLOR]

New undefined variable spewed out, also not sure what is up with the CheckforAdds, Checking XTarget for adds spam in the mq2chatwindow.

 

[Chatwiththisname]

Had gone to sleep, will check it out today if i get a chance.

 

[Chatwiththisname]

Made the correction to DevCommonPremium.inc to change ${Me.Aura[#].Equal..... to ${Me.Aura[#].Find....

Should fix the issue with no auraType Equal etc blah blah blah.

Change was made to about 12 entries throughout the DevCommonPremium.inc



The following is debugging code that in theory should only be output to the log for higherdebug. Which can be found on line 1 of code #define HIGHERDEBUG /devecholog

Please find

|  -Added a #define HIGHERDEBUG /devecholog at the very top of devCommonPremium.  This will be used for any debug statements with a level higher 
|    than 0 (default level).  The purpose of this is for people that are seeing sluggishness, can disable higher level debug calls 
|    (which can be numerous and slower) by changing this line to #define HIGHERDEBUG /squelch

information to disable this feature if it is causing problems. HIGHERDEBUG is only used 5 times in DevCommonPremium.inc

the alias code for /devecholog is found as

/squelch /alias /devecholog /call EchoLog

So basically as I understand it it's just a bunch of things pointing at each other lol. The bottom line is that HIGHERDEBUG~>/devecholog~>/call EchoLog~>Sub EchoLog(string eMsg, bool logOnly, int msgLevel)

The code for which can be found in DevCommonPremium.inc as

Sub EchoLog(string eMsg, bool logOnly, int msgLevel)
	/varset CurrentSub EchoLog
	/call Debug 3 "${CurrentSub} entered DevCommonPremium.inc"
	/declare sMsg string local

	/if (${eMsg.Equal[NULL]})	/return
	/if (${logOnly} == NULL) /varset logOnly FALSE
	/if (${msgLevel} == NULL) /varset msgLevel 0

	/if (${msgLevel} <= ${debugLvl}) {
		/call StripText "${eMsg}"
		/varset sMsg ${Macro.Return}
		/varset eMsg ${defaultEchoColor}${eMsg}
		/if (!${colorEcho}) /varset eMsg ${sMsg}
		/if (!${logOnly} || ${debugMode}) /myecho >> ${eMsg}
	
		/mqlog ${sMsg}
	}
/return

HIGHERDEBUG "Checking XTarget for adds" TRUE 5

HIGHERDEBUG "CheckForAdds completed.  newAddID: ${newAddID" TRUE 5

was changed to

HIGHERDEBUG "CheckForAdds completed.  newAddID: ${newAddID}" TRUE 5

for the missing } at the end of ${newAddID}. ~ This message is part of HIGHERDEBUG and should go away when you turn off the debug

/if (${setTimer.Equal[NULL]}) /varset setTimer ${Spell[${singleMez}].Duration.Float}s

I do a search for singleMez and it doesn't appear to have ever been declared. Will require more research to find where it should be declared and where the declaration should come from, IE: the INI or hard coded? ~~${singleMez} is only used in one place in bardBot.mac ~checking to see if a different variable is supposed to be used instead. This is part of Sub MezList....

/call MezList ~ list in bardBot.mac

Search "/call MezList" (5 hits in 1 file)
  C:\MacroQuest2\Macros\bardBot.mac (5 hits)
	Line 504: 				/call MezList CHECK ${Target.ID}
	Line 831: 			/call MezList ADD ${Target.ID} 130
	Line 837: 			/call MezList ADD ${Target.ID} 30m
	Line 932: 	/call MezList UPDATE
	Line 948: 					/call MezList CHECK ${targArray[${nArray}]}

[Songs]
MezSong=Slumber of the Sionachie
MezGem=8

found in the INI.

Loading for INI Settings finds

	/call GetINISetting ${iniName} Songs MezSong mezSong NULL
	/call GetINISetting ${iniName} Songs MezGem mezGem 0

With that said

/if (${setTimer.Equal[NULL]}) /varset setTimer ${Spell[${mezSong}].Duration.Float}s

instead of

/if (${setTimer.Equal[NULL]}) /varset setTimer ${Spell[${singleMez}].Duration.Float}s

should do the trick.

 

[Chatwiththisname]

believe I found the right variable for singleMez, which is mezSong. Correction was made and bardBot.mac updated in previous post.

 

[aspire2008]

Ran the newest version of bard you posted with the new devcommonpremium:

Toon - [2017/12/25 11:33:41] bardbot.mac@857 (MezList(string Action, int AddID, string setTimer)): /if (${setTimer.Equal[NULL]}) /varset setTimer ${Spell[${mezSong}].Duration.Float}s
Toon - [2017/12/25 11:33:41] bardbot.mac@932 (MezRoutine): /call MezList UPDATE
Toon - [2017/12/25 11:33:41] bardbot.mac@502 (Combat): /if (${mezEnabled}) /call MezRoutine
Toon - [2017/12/25 11:33:41] bardbot.mac@220 (main(string iniNameStr)): /call Combat

Toon - [2017/12/25 11:33:42] WARNING: Undefined Variable combatGem used on line 489@bardbot.mac } else /if (((${combatSong${twistPos}.Equal[NULL]} && !${combatGem${twistPos}}) || ${Me.GemTimer[${combatGem[${twistPos}]}]}) && !${twistTimer}) {Macro Paused.

Also, still not sure why the shamanbot.mac file you posted on page 4 of this thread (the last shamanbot.mac posted), it keeps ending the macro soon as I start it with "/mac shamanbot customname".

Couldn't open include file:
C:\Macroquest2\Macros\shamanBotSettings.ini
The current macro has ended.
Unable to add macro line.

 

[Chatwiththisname]

No sure why I had #include shamanBotSettings.ini in the code, but i removed it. I apparently didn't have that in my copy, I must have removed it and failed to save the change before the previous upload.

 

[aspire2008]

Shamanbot loaded with the latest version you just posted on post #56 (going to try and include post # from now on so its easier to find stuff)

Shamanbot undefined variable (probably global across all 16 mac files, as I think I saw this issue on wizard):

Toon - [2017/12/25 12:44:04] WARNING: Undefined Variable commandFrom used on line 4177@devCommonPremium.inc /if (${Bool[${Ini[${ININame},${INISection},${INIKey}]}]}) {Macro Paused.

 

[Chatwiththisname]

Shamanbot loaded with the latest version you just posted on post #56 (going to try and include post # from now on so its easier to find stuff)

Shamanbot undefined variable (probably global across all 16 mac files, as I think I saw this issue on wizard):

Toon - [2017/12/25 12:44:04] WARNING: Undefined Variable commandFrom used on line 4177@devCommonPremium.inc /if (${Bool[${Ini[${ININame},${INISection},${INIKey}]}]}) {Macro Paused.

Going to need more information. I've turned on debug to 3 in the DevCommonPremium.inc please download and use this, then return the log file to me once you get the error in shamanbot.mac

I can't find commandFrom used in shamanbot.mac or devCommonPremium anywhere, so I'll need the debug output from it to know more about it.

 

[aspire2008]

Shamanbot loaded with the latest version you just posted on post #56 (going to try and include post # from now on so its easier to find stuff)

Shamanbot undefined variable (probably global across all 16 mac files, as I think I saw this issue on wizard):

Toon - [2017/12/25 12:44:04] WARNING: Undefined Variable commandFrom used on line 4177@devCommonPremium.inc /if (${Bool[${Ini[${ININame},${INISection},${INIKey}]}]}) {Macro Paused.

Going to need more information. I've turned on debug to 3 in the DevCommonPremium.inc please download and use this, then return the log file to me once you get the error in shamanbot.mac

I can't find commandFrom used in shamanbot.mac or devCommonPremium anywhere, so I'll need the debug output from it to know more about it.

Commandfrom I think is a TLO probably in devcommonpremium, Dev uses to control commands you can use in the [Commands] section of the ini file.

Commandfrom is specific for targeting the person who sent the command over netbots or EQBC I think possibly.

So for example in my ini I have:

[Commands]
EQBCCommands=TRUE
GroupCommands=FALSE
TellCommands=TRUE
echoCommands=TRUE

CommandTrigger7=sshrink
CommandTrigger7Action1=/target ${commandFrom}
CommandTrigger7Action2=/delay 3s
CommandTrigger7Action3=/casting "Shrink" gem10
CommandTrigger7Action4=/delay 3s
CommandTrigger7Action5=NULL

So if I use the trigger phrase on a toon, it will tell the shaman to target the person who sent the command and shrink that toon. If that makes sense. I used it on the wizardbot to setup Translocation requests from a toon.


Its similar to doing /reversetarget in the base EQ game without mq.

 

[Chatwiththisname]

Shamanbot loaded with the latest version you just posted on post #56 (going to try and include post # from now on so its easier to find stuff)

Shamanbot undefined variable (probably global across all 16 mac files, as I think I saw this issue on wizard):

Toon - [2017/12/25 12:44:04] WARNING: Undefined Variable commandFrom used on line 4177@devCommonPremium.inc /if (${Bool[${Ini[${ININame},${INISection},${INIKey}]}]}) {Macro Paused.

Going to need more information. I've turned on debug to 3 in the DevCommonPremium.inc please download and use this, then return the log file to me once you get the error in shamanbot.mac

I can't find commandFrom used in shamanbot.mac or devCommonPremium anywhere, so I'll need the debug output from it to know more about it.

Commandfrom I think is a TLO probably in devcommonpremium, Dev uses to control commands you can use in the [Commands] section of the ini file.

Commandfrom is specific for targeting the person who sent the command over netbots or EQBC I think possibly.

So for example in my ini I have:

[Commands]
EQBCCommands=TRUE
GroupCommands=FALSE
TellCommands=TRUE
echoCommands=TRUE

CommandTrigger7=sshrink
CommandTrigger7Action1=/target ${commandFrom}
CommandTrigger7Action2=/delay 3s
CommandTrigger7Action3=/casting "Shrink" gem10
CommandTrigger7Action4=/delay 3s
CommandTrigger7Action5=NULL

So if I use the trigger phrase on a toon, it will tell the shaman to target the person who sent the command and shrink that toon. If that makes sense. I used it on the wizardbot to setup Translocation requests from a toon.


Its similar to doing /reversetarget in the base EQ game without mq.

Have you tried removing the TLO from your INI and seeing if you still get the error?

/call GlobalCommands ${rFrom} "${rMsg}" ${rFromEQBC}

found in Sub Event_rTell(rLine,string rFrom,string rMsg, string rType)

	/if (!${Defined[commandFrom]}) {
		/declare commandFrom							string outer ${comFrom}
		/declare commandText							string outer ${comText}
		/declare commandFromEQBC					string outer ${fromEQBC}
	} else {
		/varset commandFrom ${comFrom}
		/varset commandText ${comText}
		/varset commandFromEQBC ${fromEQBC}
	}

which is from

Sub GlobalCommands(string comFrom, string comText, bool fromEQBC)

Basically, commandFrom isn't defined until you trigger a tell event. So it's possible that it's going to remain undefined until that occurs. Which will cause the undefined variable. In otherwords using it in the INI is likely triggering the error. If you remove #warning then you'll prevent the macro from pausing for that issue and when you get a tell event it will populate that information and hopefully trigger the command.