Macro devBots - Updated for MQ2 undeclared variables patch 09/16/2017

[devestator]

Hey everyone,
I spent a few hours tonight running through and updating all the problematic code that I saw relating to the recent patch dealing with undeclared variables in my bots. I didn't have time to fully test everything, I'll leave that up to you guys.

You can get the most recent version of the bots from the master branch at: GitHub - devestator/devbots: All Everquest / MQ2 class bots and other macros written by devestator

Note, nearly every file required changes, except for the INI config files. So make sure you update all of your dev* files as well as the bot files themselves.

I tested enough to make sure they loaded participated in combat and did buffs / cast spells etc. But I only tested on the monk and shaman. It's entirely possible that I made a typo or simply missed changing a line somewhere.

So please use this thread to post any problems you encounter with them.

Also, I went ahead and included the fix from the Aura problem from a couple of weeks ago in this update as well. So you do not have to re-apply that fix if you had done it previously.

For anyone who does use them regularly, I'd be interested in knowing if you see any noticeable performance improvements from this? eqMule said the changes to MQ2 should see a pretty big improvement and I'm just curious how much of an impact it has on my bots.

 

[Carbja23]

Hey everyone,
I spent a few hours tonight running through and updating all the problematic code that I saw relating to the recent patch dealing with undeclared variables in my bots. I didn't have time to fully test everything, I'll leave that up to you guys.

You can get the most recent version of the bots from the master branch at: GitHub - devestator/devbots: All Everquest / MQ2 class bots and other macros written by devestator

Note, nearly every file required changes, except for the INI config files. So make sure you update all of your dev* files as well as the bot files themselves.

I tested enough to make sure they loaded participated in combat and did buffs / cast spells etc. But I only tested on the monk and shaman. It's entirely possible that I made a typo or simply missed changing a line somewhere.

So please use this thread to post any problems you encounter with them.

Also, I went ahead and included the fix from the Aura problem from a couple of weeks ago in this update as well. So you do not have to re-apply that fix if you had done it previously.

For anyone who does use them regularly, I'd be interested in knowing if you see any noticeable performance improvements from this? eqMule said the changes to MQ2 should see a pretty big improvement and I'm just curious how much of an impact it has on my bots.

Thanks Dev, I'll let you know this week hopefully for well they work.

 

[Marnan]

Thanks Dev, I still use two of your macros. I'm on vacation until 9/25, so I won't be testing them until I get back.

 

[dewey2461]

I'd be interested in knowing if you see any noticeable performance improvements from this? eqMule said the changes to MQ2 should see a pretty big improvement and I'm just curious how much of an impact it has on my bots.

I'm not running your macros so I can't speak about any performance differences in your code, but the 8000 line monster of a macro I use had about 10 undefined variables in the old spell_casting.inc routines and there has been no noticeable performances differences pre/post.

I suspect you're really need to have a shit ton of undeclared getting hit in a tight main loop, like the plugins that he updated.

 

[nookiecookie]

Somethings for Bardbot:

Line 163 needs to be updated, it had wrong version number in it.

/declare meVersion						float outer 1.29

There are issues with lines 427 and 242. That caused macro to close.

 

[devestator]

Somethings for Bardbot:

Line 163 needs to be updated, it had wrong version number in it.

/declare meVersion						float outer 1.29

There are issues with lines 427 and 242. That caused macro to close.

Ok, those 2 things should be fixed in the master branch now. Line 242 was just where it called the function that had the problem on line 427, so the fix on line 427 should be all that was needed for it.

 

[Chatwiththisname]

Hi Dev,

First I wanted to thank you for uploading the git in the first place.

Secondly, do the updated files include the changes made for the Auras? I made a change directly to bardbot because for some reason bard aura was hard coded directly into the macro, while others were updated using the dev* files. There was a thread running around here somewhere, I just wanted to confirm those fixes prior to trying your macros. I don't really play the game, more of a community support figure at this point. So I'm unlikely to provide any feedback unless I specifically run them for error checking reasons.

Finally, thanks for making an appearance after the original commit, which was done on the basis that you were no longer providing support for the macros.

~Chat

 

[devestator]

Hi Dev,

First I wanted to thank you for uploading the git in the first place.

Secondly, do the updated files include the changes made for the Auras? I made a change directly to bardbot because for some reason bard aura was hard coded directly into the macro, while others were updated using the dev* files. There was a thread running around here somewhere, I just wanted to confirm those fixes prior to trying your macros. I don't really play the game, more of a community support figure at this point. So I'm unlikely to provide any feedback unless I specifically run them for error checking reasons.

Finally, thanks for making an appearance after the original commit, which was done on the basis that you were no longer providing support for the macros.

~Chat

Yes, the aura change is included.

I think the reason the bards Aura is coded differently from other classes is because of the unique way that bards casting is done.

But honestly... I don't remember for sure

 

[devestator]

I don't know if anyone has tested these versions of the bots yet, but based on information in another post, with a recent change to how /for /next loops there is likely to be some oddities in many behaviors with the bots. I honestly can't say how much stuff would be effected right now, but pretty sure healing in the bots that heal and possibly some buffing routines and such.

This change is going to take a far greater amount of time for me to look at and fix than the undeclared, so it's not going to be immediate. I can't set aside that much time at once right now.

It's going to require going through every loop, looking to see if it has a problematic /next call in it, analyzing what the purpose of that is, and deciding how best to change it. In a lot of cases the problematic /next can probably be replaced with /continue. But there are going to be some where that is probably not going to be sufficient and will require some rewriting of the logic in the for loop.

If anyone else wants to take a shot at it, you basically would need to look for any /for /next loops that have multiple /next for the same variable (not to be confused with nested /for /next loops). If there are multiple /next for the same variable then it has to be rewritten so that there is only one /next at the very end of the loop. Like I said, in a lot of cases the other inner /next's would be replaced with /continue. But there may be some cases of needing to do /break or such.

 

[Carbja23]

I don't know if anyone has tested these versions of the bots yet, but based on information in another post, with a recent change to how /for /next loops there is likely to be some oddities in many behaviors with the bots. I honestly can't say how much stuff would be effected right now, but pretty sure healing in the bots that heal and possibly some buffing routines and such.

This change is going to take a far greater amount of time for me to look at and fix than the undeclared, so it's not going to be immediate. I can't set aside that much time at once right now.

It's going to require going through every loop, looking to see if it has a problematic /next call in it, analyzing what the purpose of that is, and deciding how best to change it. In a lot of cases the problematic /next can probably be replaced with /continue. But there are going to be some where that is probably not going to be sufficient and will require some rewriting of the logic in the for loop.

If anyone else wants to take a shot at it, you basically would need to look for any /for /next loops that have multiple /next for the same variable (not to be confused with nested /for /next loops). If there are multiple /next for the same variable then it has to be rewritten so that there is only one /next at the very end of the loop. Like I said, in a lot of cases the other inner /next's would be replaced with /continue. But there may be some cases of needing to do /break or such.

Doh, this pretty much kills my ability to play the game. I use a combination of bot plugin, bot40.mac and your bard bot for my group of 6. Wish this change didn't happen, but I'm sure its for the better.

 

[jamie75]

meleeassist mac is getting some errors, traveling today on my surface and didn't get a chance to copy the errors down before my flight

 

[budlight]

Here is a few things I have found so far with new uploads to github:


Sham and cleric bot don't load .ini :
[09/23/2017 12:57:20] Initialized devCommonPremium.inc v2.51 - Written By Devestator
[09/23/2017 12:57:20] Initializing devMovementPremium.inc v1.74 - Written By Devestator
[09/23/2017 12:57:20] Initializing devCast.inc v1.06
[09/23/2017 12:57:20] Loading Bot specific configuration...
[09/23/2017 12:57:20] Shamanbot v1.25 Initialized
[09/23/2017 12:57:20] Loading variables...

Bard bot seems to load and run fine so far:

Sk bot loads ini ok then gets these errors:
devCommonPremium.inc@1993
devCommonPremium.inc@1637
skbot.mac@128

Enhanter bot seems to load and run fine so far:

War bot seems to load and run fine so far:

Mage bot loads ini then gets this:
[09/23/2017 13:18:21] The version of magebot2.mac v4.17 you are using is not supported with this version of devCommonPremium.inc v2.51: Required Version: 4.18

Necro bot loads ini ok then gets these errors:
devCommonPremium.inc@1993
devCommonPremium.inc@1637
necrobot.mac@162
and spams Merc stance


Hope some of this helps.

 

[Boston]

Dev Bots

I am also having these same issues with not loading ini file. Also none of my toons will loot corpses now either. I have not seen anyone else complain about this and wonder if it is something on my end. If anyone else is having a looting issue can you let me know. Thanks

 

[Chatwiththisname]

Here is a few things I have found so far with new uploads to github:


Sham and cleric bot don't load .ini :
[09/23/2017 12:57:20] Initialized devCommonPremium.inc v2.51 - Written By Devestator
[09/23/2017 12:57:20] Initializing devMovementPremium.inc v1.74 - Written By Devestator
[09/23/2017 12:57:20] Initializing devCast.inc v1.06
[09/23/2017 12:57:20] Loading Bot specific configuration...
[09/23/2017 12:57:20] Shamanbot v1.25 Initialized
[09/23/2017 12:57:20] Loading variables...

Bard bot seems to load and run fine so far:

Sk bot loads ini ok then gets these errors:
devCommonPremium.inc@1993
devCommonPremium.inc@1637
skbot.mac@128

Enhanter bot seems to load and run fine so far:

War bot seems to load and run fine so far:

Mage bot loads ini then gets this:
[09/23/2017 13:18:21] The version of magebot2.mac v4.17 you are using is not supported with this version of devCommonPremium.inc v2.51: Required Version: 4.18

Necro bot loads ini ok then gets these errors:
devCommonPremium.inc@1993
devCommonPremium.inc@1637
necrobot.mac@162
and spams Merc stance


Hope some of this helps.

The exact error in MQ2 window or from the Log file would be invaluable in assisting with troubleshooting. Without that, below is all I know about the errors in devCommonPremium.inc

Line 1993 is Aura related from the looks of the code.

Lines 1992 to 2004

/if (${buffText[${nArray}].NotEqual[NULL]}) {
						/if (${Me.Aura[1].Name.Equal[${buffText[${nArray}]}]} || ${Me.Aura[1].Name.Equal[${buffName[${nArray}]}]} || ${Me.Aura[2].Name.Equal[${buffText[${nArray}]}]} || ${Me.Aura[2].Name.Equal[${buffName[${nArray}]}]}) {
							| Work around for MQ2 aura bug
						} else {
							/if ((!${Me.Buff[${buffText[${nArray}]}].ID} || ${Me.Buff[${buffText[${nArray}]}].Duration} <= ${Math.Calc[${Spell[${buffName[${nArray}]}].Duration.TotalSeconds}/10]}) && !${Me.Song[${buffText[${nArray}]}].ID}) /call CastBuff ${Me.ID} ${nArray} SELF
						}
					} else {
						/if (${Me.Aura[1].Name.Equal[${buffName[${nArray}]}]} || ${Me.Aura[2].Name.Equal[${buffName[${nArray}]}]}) {
							| Work around for MQ2 aura bug
						} else {
							/if ((!${Me.Buff[${buffName[${nArray}]}].ID} ||  ${Me.Buff[${buffName[${nArray}]}].Duration} <= ${Math.Calc[${Spell[${buffName[${nArray}]}].Duration.TotalSeconds}/10]})) /call CastBuff ${Me.ID} ${nArray} SELF
						}
					}

According to the Wiki the Aura data type is a string and returns a name, it doesn't specify if it is an Array. I believe the Wiki to be outdated in this respect due to the recent change to the Aura datatype. I use ${Me.Aura.Name.Equal[AuraNameHere]} in my checks. Not all to certain that ${Me.Aura[1].Name.Equal[Something]} works. Suppose that it should be an array though, for when You're able to have multiples (enchanter??). But if it does I don't see an issue with it unless it's due to an undeclared variable.


Below is 1635 to 1639

/if (${checkTypes.Length}) {
		/varset checkTypes |${checkTypes}
		/call buffCheckRoutine ${checkTypes} ${combatBuff} ${onCallRoutine}
	}
/return

 

[boxeq]

Magebots2.mac will not load i get this "[09/25/2017 07:08:28] The version of magebot2.mac v4.17 you are using is not supported with this version of devCommonPremium.inc v2.51: Required Version: 4.18"


Was a download of the 4.18 mac and even did a copy/paste of the mac from github didn't work same error. Cleric/shaman will load and stop at "[09/25/2017 08:53:12] Initialized devCommonPremium.inc v2.51 - Written By Devestator
[09/25/2017 08:53:12] Initializing devMovementPremium.inc v1.74 - Written By Devestator
[09/25/2017 08:53:12] Initializing devCast.inc v1.06
[09/25/2017 08:53:12] Loading Bot specific configuration...

Both stop here.

 

[Boston]

Dev Bots

I have a continued error while running any of the bots as looter.


Could not send notification to 66 mouseup
[/itemnotify] Invalid item slot 'null'

That's all it spams no line# or anything else I can see in MQ2 in game window.
If anyone has a clue what I might have borked or know how to fix it please let me know . Thanks

 

[Chatwiththisname]

I have a continued error while running any of the bots as looter.


Could not send notification to 66 mouseup
[/itemnotify] Invalid item slot 'null'

That's all it spams no line# or anything else I can see in MQ2 in game window.
If anyone has a clue what I might have borked or know how to fix it please let me know . Thanks

Probably due to AdvLoot would be my guess. Looking at the looting routines it's targeting corpses and trying to loot them directly. But with the current looting system it isn't really nessesary/allowed to function in that way.

It basically /target ${Corpse} from an array of killed mobs, then /loot, once the box is open it checks the window for loot, then tries to /itemnofity the slot in the loot window which would place the item on the cursor. But when you /loot with advloot it won't open the corpse unless the timer has expired in the advloot window as I understand it. Thus it can't notify anything.

 

[devestator]

I have a continued error while running any of the bots as looter.


Could not send notification to 66 mouseup
[/itemnotify] Invalid item slot 'null'

That's all it spams no line# or anything else I can see in MQ2 in game window.
If anyone has a clue what I might have borked or know how to fix it please let me know . Thanks

Probably due to AdvLoot would be my guess. Looking at the looting routines it's targeting corpses and trying to loot them directly. But with the current looting system it isn't really nessesary/allowed to function in that way.

It basically /target ${Corpse} from an array of killed mobs, then /loot, once the box is open it checks the window for loot, then tries to /itemnofity the slot in the loot window which would place the item on the cursor. But when you /loot with advloot it won't open the corpse unless the timer has expired in the advloot window as I understand it. Thus it can't notify anything.

No, this is not a problem dealing with MQ2AdvLoot.

And yes, my loot routines still rely on using the old loot method, not the new one. The new one doesn't really need anything in the routines. You can configure EQ to handle looting directly by itself IIRC.

I've already tracked down the problem with looting but there are a host of other problems that need to be fixed now as well. Namely, all the work I did last week to get them back up and running somewhat, has to be done mostly all again due to a second change in the way undefined function arguments are handled.

The problem with looting is due to the changes made to /for /next loops. When it loops through the corpse items there is one spot where it would skip an item for various reasons, and it does a /next call there and has to be changed to a /continue.

 

[Boston]

Awesome! Well beyond my expertise atm, so I will wait for the big dogs to handle this business. I appreciate the attention you are still giving to your bots Dev. Chatwith you have been extremely helpful on many topics, again I just want to say thanks to both of you.

 

[Chatwiththisname]

I have a continued error while running any of the bots as looter.


Could not send notification to 66 mouseup
[/itemnotify] Invalid item slot 'null'

That's all it spams no line# or anything else I can see in MQ2 in game window.
If anyone has a clue what I might have borked or know how to fix it please let me know . Thanks

Probably due to AdvLoot would be my guess. Looking at the looting routines it's targeting corpses and trying to loot them directly. But with the current looting system it isn't really nessesary/allowed to function in that way.

It basically /target ${Corpse} from an array of killed mobs, then /loot, once the box is open it checks the window for loot, then tries to /itemnofity the slot in the loot window which would place the item on the cursor. But when you /loot with advloot it won't open the corpse unless the timer has expired in the advloot window as I understand it. Thus it can't notify anything.

No, this is not a problem dealing with MQ2AdvLoot.

And yes, my loot routines still rely on using the old loot method, not the new one. The new one doesn't really need anything in the routines. You can configure EQ to handle looting directly by itself IIRC.

I've already tracked down the problem with looting but there are a host of other problems that need to be fixed now as well. Namely, all the work I did last week to get them back up and running somewhat, has to be done mostly all again due to a second change in the way undefined function arguments are handled.

The problem with looting is due to the changes made to /for /next loops. When it loops through the corpse items there is one spot where it would skip an item for various reasons, and it does a /next call there and has to be changed to a /continue.

I apologize if I misspoke. I was actually referring to the new way that EQ handles looting and not MQ2AdvLoot. I'm not sure why I decided to call it AdvLoot as I've never used the plugin. But yeah, basically was saying turn the looting off and let EQ do the looting.