Any update to these yet? Macros basically sitting at a stand still with the errors and loading.... issues since last patch.
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.
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
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.
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.
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.
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.
/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
}