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

[boxeq]

Any update to these yet? Macros basically sitting at a stand still with the errors and loading.... issues since last patch.

 

[Carbja23]

Anyone have Devcommonpremium.inc version version 2.51? I overwrote with some of the changes listed in the thread and can't use the old compile (without the macro changes). Group is pretty much dead in the water atm.

 

[Chatwiththisname]

Any update to these yet? Macros basically sitting at a stand still with the errors and loading.... issues since last patch.

Need more information. #warning at the top of the macro before sub main.

Run macro.

Get list of undeclared variables.

Goto /Macroquest2/logs folder, find your characters log file. Copy and paste into Window with code blocks around it. ~Be sure to remove any character names. IE: Ctrl-F type character name in box. Hit next, delete anywhere it shows up which is typically on the left side of the window.

Tell us which bot is being used.

Tell us which DevCommonPremium inc file you are using.

being vague never helped a programmer fix anything.

 

[EQDAB]

I suspect they are a lot closer to primetime then expected, Dev was always a great coder & wonderful source of support for all here. But just an OldOne's opinion. Thanks 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.

 

[mcsethanon]

Is there a wiki or doc for these macros? I have OutOfCombatSit set to FALSE, but they still sit. My tank's GroupRole is set to maintank, but the macro doesn't recognize that so it sets him to DPS.

Thanks

 

[Chatwiththisname]

Is there a wiki or doc for these macros? I have OutOfCombatSit set to FALSE, but they still sit. My tank's GroupRole is set to maintank, but the macro doesn't recognize that so it sets him to DPS.

Thanks

This is a garbage in garbage out system. You tell me you don't sit, I ask you on which macro

 

[mcsethanon]

So far, specifically the WarriorBot and BeastlordBot. They're the only 2 I've tried thus far. I'm betting they all give me the same result, but I can verify.

 

[devestator]

Is there a wiki or doc for these macros? I have OutOfCombatSit set to FALSE, but they still sit. My tank's GroupRole is set to maintank, but the macro doesn't recognize that so it sets him to DPS.

Thanks

So far, specifically the WarriorBot and BeastlordBot. They're the only 2 I've tried thus far. I'm betting they all give me the same result, but I can verify.

INIs aren't loading correctly atm due to the 2nd change with undefined function variables. I believe the INI being loaded by default right now would be for example warriorBotSettings_NULL.ini So any INI settings you have in warriorBotSettings.ini would be ignored. I have not had time to go back and fix them again yet. No one else seems up to doing updates on the bots either, so unfortunately it's just going to have to wait until I get a spare few hours again.

It's really hard for me to come up with that much time at once right now, which is why it was so frustrating that it was changed again after I had already made time to fix it the first time.

 

[Chatwiththisname]

Fixed some undeclared variable issues for warriorbot, devcommonpremium.inc, devpull.inc

Added #Warning to the top of the macro. You can delete that line if your macro is pausing on you. But if it is pausing it's because more undeclared variables were found and you must provide feedback for the fix. It will tell you what variable is undefined in green and reference you to the line of code and the line it was used on. Dev needs this information to fix his macros!

I don't use this macro. I didn't even have a warrior but thanks to loyalist points I got a doll and made one. This was tested with a level 1 warrior with NOTHING added to the INI.

Issues I've noticed. It's not automatically populating the ini with missing ini keys.

Updating a macro based on a level 1 warrior is probably silly.

For Dev. For your parameter variables use ${Bool[${VariableName}]} and if it isn't empty it will return true. This only applies to parameters. Such as choosing which INI to load in warrior bot. It was finding that iniNameStr was not NULL, but rather just blank. You can't just check to see if it is declared because parameters are automatically declared. Thus you need to use ${Bool[]} and if the value is anything other than 0 or NULL it will return true. Note: The fix to load the correct INI is in warriorbot.mac

one of your /call GetINISettings is trying to declare Group. This is already a used variable by MQ2Main as I understand it. Thus it fails. I didn't fix this because I don't know where the call to the ini settings is and searching for the word "Group" is like picking through a haystack looking for a certain piece of hay, fuck the needle lol. But it doesn't end the macro so I left it be.

I'm not super familiar with commits and pushes etc. I sent a commit because I don't have pull access.

 

[devestator]

For Dev. For your parameter variables use ${Bool[${VariableName}]} and if it isn't empty it will return true. This only applies to parameters. Such as choosing which INI to load in warrior bot. It was finding that iniNameStr was not NULL, but rather just blank. You can't just check to see if it is declared because parameters are automatically declared. Thus you need to use ${Bool[]} and if the value is anything other than 0 or NULL it will return true. Note: The fix to load the correct INI is in warriorbot.mac

one of your /call GetINISettings is trying to declare Group. This is already a used variable by MQ2Main as I understand it. Thus it fails. I didn't fix this because I don't know where the call to the ini settings is and searching for the word "Group" is like picking through a haystack looking for a certain piece of hay, fuck the needle lol. But it doesn't end the macro so I left it be.

I'm not super familiar with commits and pushes etc. I sent a commit because I don't have pull access.

Chatwiththisname,
I appreciate your attempt at helping. The reason iniNameStr was checking for "NULL" (and many other function string arguments) is because that is how it had to be done after the initial patch to function arguments that weren't passed into functions. Non strings were set equal to NULL, but strings were set equal to "NULL". So you still had to do a string comparison for "NULL" on strings. It was changed in a follow up patch so that strings were set equal to NULL as well. That was after I had already done all the work to change all my Defined checks to != NULL checks and strings to .NotEqual[NULL]. Which btw using != NULL would be better than wrapping it in ${Bool[]} IMO. Wrapping it in ${Bool[]} would essentially cause 2 operations (converting to a bool value then checking if the bool value is true) instead of 1 (simply checking != NULL), thus ${Bool[]} will be slightly slower in the long run.

The "Group" variable in the GetINISettings function is most likely a similar issue with a function string parameter having been changed to check for .Equal[NULL].

Basically, what I'm going to have to do when I get a few hours is look at the diff between the current version and the pre-patch version to find all the locations that I changed to .Equal[NULL] or .NotEqual[NULL] and change them to == or != NULL instead of a string comparison. It's an easy but very time consuming and tedious change because there are so many occurrences of it across so many files. So if anyone else feels up to doing it, I can help you get started and show you how to pull the previous versions off git to do the diff with. I just can't sit down and do them all myself right now.

Beyond that, problematic multiple /next in /for loops still need to be found and updated to /continue and probably in some cases the entire /for logic will need to be changed.

 

[Chatwiththisname]

Chatwiththisname,
I appreciate your attempt at helping. The reason iniNameStr was checking for "NULL" (and many other function string arguments) is because that is how it had to be done after the initial patch to function arguments that weren't passed into functions. Non strings were set equal to NULL, but strings were set equal to "NULL". So you still had to do a string comparison for "NULL" on strings. It was changed in a follow up patch so that strings were set equal to NULL as well. That was after I had already done all the work to change all my Defined checks to != NULL checks and strings to .NotEqual[NULL]. Which btw using != NULL would be better than wrapping it in ${Bool[]} IMO. Wrapping it in ${Bool[]} would essentially cause 2 operations (converting to a bool value then checking if the bool value is true) instead of 1 (simply checking != NULL), thus ${Bool[]} will be slightly slower in the long run.

The "Group" variable in the GetINISettings function is most likely a similar issue with a function string parameter having been changed to check for .Equal[NULL].

Basically, what I'm going to have to do when I get a few hours is look at the diff between the current version and the pre-patch version to find all the locations that I changed to .Equal[NULL] or .NotEqual[NULL] and change them to == or != NULL instead of a string comparison. It's an easy but very time consuming and tedious change because there are so many occurrences of it across so many files. So if anyone else feels up to doing it, I can help you get started and show you how to pull the previous versions off git to do the diff with. I just can't sit down and do them all myself right now.

Beyond that, problematic multiple /next in /for loops still need to be found and updated to /continue and probably in some cases the entire /for logic will need to be changed.

But it isn't NULL, that's the point. You were evaluating for NULL but it wasn't null it was simply blank. If I /echo using your check I get a blank line. If I try to declare it it comes up as already declared. Thus the easiest way to check for it to be something but nothing at the same time was to wrap it in a bool.
I tried about 8 different things, kept deleting the IniFile_ trying to get it to use the base INI file when no parameter was supplied. The ${Bool[]} method is what worked.

You're welcome to rehash all the things I tried and see if you can come up with a more suitable method. But I'm not sure I understand the concept of trying to fix something that isn't broken.

You mentioned that nobody was jumping off bridges trying to update your code so I did a bit of that. In return I'm criticized for the way I do it. You can be sure that if this is the kind of thanks for me "trying" to help, that I'll just save myself the trouble and not go out of my way to get you a head start on any of your macros. Just thought that was what you were asking for. /shrug.

 

[devestator]

But it isn't NULL, that's the point. You were evaluating for NULL but it wasn't null it was simply blank. If I /echo using your check I get a blank line. If I try to declare it it comes up as already declared. Thus the easiest way to check for it to be something but nothing at the same time was to wrap it in a bool.
I tried about 8 different things, kept deleting the IniFile_ trying to get it to use the base INI file when no parameter was supplied. The ${Bool[]} method is what worked.

You're welcome to rehash all the things I tried and see if you can come up with a more suitable method. But I'm not sure I understand the concept of trying to fix something that isn't broken.

You mentioned that nobody was jumping off bridges trying to update your code so I did a bit of that. In return I'm criticized for the way I do it. You can be sure that if this is the kind of thanks for me "trying" to help, that I'll just save myself the trouble and not go out of my way to get you a head start on any of your macros. Just thought that was what you were asking for. /shrug.

Hmm, I'm sorry? I said I appreciated your attempt to help. I mean, that literally means I appreciated it... not sure what else to say there. I guess my appreciation wasn't good enough?

The rest you could say at worse was constructive criticism. Although it wasn't really meant as criticism as at all, just pointing out the way I had planned to change it when I got around to it. It probably came off as such because I'm used to explaining things to entry level programmers that are part of the team I lead.

I mean no offense (although judging by your last reaction you will probably take it as such), but if you can't handle criticism regardless of the type, programming may not be for you. Well unless you want to be one of those programmers with a huge ego that thinks they are untouchable and have nothing left to learn. I've had people like that work for me before, they don't tend to last long. Their ego usually ends up getting in the way when they inevitably make a mistake and they are either to proud or to embarrassed to admit it. Even the best programmer is going to be criticized at times because no one is perfect. I've been in software development for over 20 years and I welcome criticism of my work. Even after all these years I recognize that I can still learn new stuff and better ways to do things from someone that views something differently than I do.

All that said, it's possible that the function parameters changed again since the last time I looked at it? I know it was setting the string to NULL the last time I did look at it (tested and verified that stringArgument != NULL worked at that time). So I can only guess that it changed again if it's an empty string now and that evaluation no longer works on it.

 

[Chatwiththisname]

But it isn't NULL, that's the point. You were evaluating for NULL but it wasn't null it was simply blank. If I /echo using your check I get a blank line. If I try to declare it it comes up as already declared. Thus the easiest way to check for it to be something but nothing at the same time was to wrap it in a bool.
I tried about 8 different things, kept deleting the IniFile_ trying to get it to use the base INI file when no parameter was supplied. The ${Bool[]} method is what worked.

You're welcome to rehash all the things I tried and see if you can come up with a more suitable method. But I'm not sure I understand the concept of trying to fix something that isn't broken.

You mentioned that nobody was jumping off bridges trying to update your code so I did a bit of that. In return I'm criticized for the way I do it. You can be sure that if this is the kind of thanks for me "trying" to help, that I'll just save myself the trouble and not go out of my way to get you a head start on any of your macros. Just thought that was what you were asking for. /shrug.

Hmm, I'm sorry? I said I appreciated your attempt to help. I mean, that literally means I appreciated it... not sure what else to say there. I guess my appreciation wasn't good enough?

The rest you could say at worse was constructive criticism. Although it wasn't really meant as criticism as at all, just pointing out the way I had planned to change it when I got around to it. It probably came off as such because I'm used to explaining things to entry level programmers that are part of the team I lead.

I mean no offense (although judging by your last reaction you will probably take it as such), but if you can't handle criticism regardless of the type, programming may not be for you. Well unless you want to be one of those programmers with a huge ego that thinks they are untouchable and have nothing left to learn. I've had people like that work for me before, they don't tend to last long. Their ego usually ends up getting in the way when they inevitably make a mistake and they are either to proud or to embarrassed to admit it. Even the best programmer is going to be criticized at times because no one is perfect. I've been in software development for over 20 years and I welcome criticism of my work. Even after all these years I recognize that I can still learn new stuff and better ways to do things from someone that views something differently than I do.

All that said, it's possible that the function parameters changed again since the last time I looked at it? I know it was setting the string to NULL the last time I did look at it (tested and verified that stringArgument != NULL worked at that time). So I can only guess that it changed again if it's an empty string now and that evaluation no longer works on it.

I had been up for two days. Lets assume I was tired and read it as if you were annoyed with me for half assing a fix as opposed to providing constructive criticism.

I think the change to the way the parameters were read were part of the undeclared variables update. But as you said nobody is perfect. For example Aura's on shaman are read differently from every other character. Based on updates to Bot40.mac that I've done ~~

/if (!${Me.Class.ShortName.Equal[SHM]}) {
		/if (${ImNotReady}||${Me.Aura[1].Name.Length} && !${Me.AltAbility[Spirit Mastery]} && !${Me.AltAbility[Auroria Mastery]}||${Me.Aura[2].Name.Length}||${AuraDelay}||${NeedLoad}) /return
  	} else {
		/if (${ImNotReady}||${Me.Aura[1].Length} && !${Me.AltAbility[Spirit Mastery]} && !${Me.AltAbility[Auroria Mastery]}||${Me.Aura[2].Length}||${AuraDelay}||${NeedLoad}) /return
	}

Is a snippet of code I had to use to account for the TLO Members being different if you're a shaman. I've raised the issue to Macroquest2.com on their forum but as of now I haven't received a response about it being a mistake. I get offered other things I could type instead.

MacroQuest - View topic - Aura change problem. No Such 'string' member 'Name'

The idea behind the update sounds reasonable, but in old macros using the methods we've used in the past it's apparently just going to cause us to use wrappers in order to account for the current method of checking things.

IE: Instead of checking if a variable has been declared using /if (!${UseBuffs} we would check for some default value /if (${UseBuffs} != -1) and then go back and declare the value as -1 prior to updating it, then check for the INI to equal anything other than -1 to see if it has been altered from it's starting creation.

The alternate to that being typing /if (!${Defined[UseBuffs]}) /declare UseBuffs bool outer FALSE to assume that if it hasn't been defined at this point then go ahead and define it and assume it's false because if it was true then it would have been declared as such when we checked the INI. This would go just before it's first use attempt as a backup to check for the undeclared variable.

I use #Warning in everything I work on. This way it will let me know if there is an undeclared variable. It's possible that even with the undeclared variable that it will evaluate just fine when doing a /if (${SomeVar} != NULL) /dostuff, but as I understand it from EqMule the best bet is to go ahead and define it or check to see if its defined instead of checking for NULL using /if (${Defined[SomeVar]}) /dostuff

There's a lot of ways to handle the update in regards to existing code. Having just come from bot40.mac updates to get a lot of things working on it I do have a bit of experience working on both macros belonging to people other than myself and updating said code to reflect the undeclared variable changes without even actually reading much into the code itself. I did have to copy down your function for GetINISettings to try and sort out an issue with some variables being declared through that. And I commented out an echo because the variable never appeared to be defined anywhere in the macro, though it is possible it was declared through GetINISettings but was being used before it was declared. Either way, the point here is I did give it a go. Hopefully the changes, while not necessarily the best possible fix in any or all situations do actually make it usable pending your personal reconstruction of the code in a manner that avoids unnecessary wrappers etc. Since I didn't code it, I assume it would be easier for you to know what to change and where as you've created it and have a greater understanding of the project overall.

Good luck to you, recommend checking the diff for some suitable possibilities to correct some issues. Being my test was done on a level 1 warrior, and it was done without a single modification to the default ini, it's highly unlikely that I've fixed all issues and more are likely present.