Macro Bot.mac Updates and Bug Fixes by [40oz]

[devestator]

/continue is a performance improvement and works in both /for and /while loops, nested or single.

Also my OCD alarm goes off when I see /next being used as a goto improperly, so that was reason enough to change it. The change is recent and was basically pushed through by eqholic but I agree with it. It will make macros look prettier and the logic easier to follow.

Lol we are coding for aesthetics now?

/next x

/continue

Hmmm you are right, the curves in /continue are much more appealing than the mostly harsh straight lines in /next x. Definitely prettier code that way

Yes, I'm joking, mostly lol. I do disagree with a huge macro breaking change for code aesthetics sake though. As a professional developer myself, when changing old stuff, or even creating new stuff, I strongly believe in backwards compatibility unless there is a significant reason not to in order to make transitions into new features as smooth as possible. But, I also have to worry about how many man hours it's going to take to change affected code and things like that. I suppose in your case you don't really have to worry about how much time it's going to take everyone else to change their macros and such.

If it's a significant performance improvement then ok, that is understandable. I haven't ever looked at how the parser works but I thought it parsed and executed line by line. This change, and it being a performance improvement, seem to imply that it parses the entire loop before it executes the lines in it. Maybe some day I'll be bored and have time to look at the parser code and learn how it actually works lol

 

[eqmule]

Well I was a dev at a fortune 100 company for several years and when you actually get paid you take the end users and their workload into account or it will cost you your job, but being the lead dev for mq2 is a little bit different, I kinda do as I please because without me there wouldn't be a mq2 at all... yeah I know that's arrogant etc, but there is some truth in the fact that I can afford to make changes purely for esthetic reasons, since it is extremely outweighed by all the other great features and fixes I add... and have added.

In this case I decided many aspects of the whole engine needed a revamp and fixing continue and next was just side effects of that rewrite. With visual studio 2017 CPU profiling you can actually see about a 40% increase in performance in the engine. Could I have left next alone? Sure but it would have come at a cost. (2% slower in my test for just /next and yeah that doesn't sound like much but it adds up when you take into account that that's per CPU cycle)

 

[[40oz]]

/continue is a performance improvement and works in both /for and /while loops, nested or single.

Also my OCD alarm goes off when I see /next being used as a goto improperly, so that was reason enough to change it. The change is recent and was basically pushed through by eqholic but I agree with it. It will make macros look prettier and the logic easier to follow.

Thanks for the clarification. I'm glad to know there is a way to short circuit for loops cleanly. I didn't have a problem aesthetically with multiple /next <var>, but I also did not realize it wasn't meant to be used that way.


poly:

I'll try to integrate those changes later if I get my packing done on time. I get on a 13 hour plane in 19 hours, and I still have quite a bit of packing and a need for sleep, to do. I think most of your changes are correct; I'll review them in more detail when I can sit down and focus on code.

 

[poly]

poly:

I'll try to integrate those changes later if I get my packing done on time. I get on a 13 hour plane in 19 hours, and I still have quite a bit of packing and a need for sleep, to do. I think most of your changes are correct; I'll review them in more detail when I can sit down and focus on code.

Also, the space between "Main" and "(" means those variables don't get declared:

Sub Main (string Param0, string Param1)

 

[poly]

First pic shows what happens when the macro tries to cast an aura (not sure why, but non-aura spells cast fine), this can be fixed by changing sub aura to use /casting instead of /call cast....

2nd pic shows undeclared variables list for a cleric with a previously functioning ini, just sitting idle (not really idle, tries to spam cast buffs over and over)...

In combat, AAs, fightbuffs, nukes, maintank buffs, heal single, xtarget heal *seem* to work....

Buffs, dots and debuffs got some major issues.

 

[poly]

Is anyone working on this?

I have it partially working:

Healspash	NOT TESTED
HealGroup     	OK
HealBalance    	OK
HealSelf       	NOT TESTED
HealXtarget    	OK
HealPet        	NOT TESTED
Nuke            OK
Dot             Partially Working (Doesn't seem to cast them often)
Mez             NOT WORKING
Bard            NOT WORKING
Pulling		NOT TESTED
Loot		WORKING
Debuff		Partially Working (Debuffs Kill Target but not Adds)
Buff		COMPLETELY MESSED UP (And I don't know how to fix it)
Rez		OK
SelfBuff	OK
Aura		OK
Endurance	NOT TESTED
MAna		NOT TESTED
Modrod		NOT TESTED
Merc		NOT TESTED
FD		NOT TESTED
Cure		NOT TESTED
MT Buff		OK
AA		OK
Fade		NOT TESTED
Lifetap		NOT TESTED
Jolt		NOT TESTED
Snare		NOT TESTED
Root		NOT TESTED
Clicky Nuke	OK
ImHit		OK

Other Stuff:
*There is something wrong with Clear target events (they don't work at all)
*I haven't tested /mac bot40 load (no idea what will happen)
*I found that some features just never worked properly die to typos/undelcared variables (such as Interrupt to heal).


I'm not a programmer, so some of the "fixes" are probably very poor. Am happy to work with others on getting it fixed, but I'm sure that someone who knows what they are doing will be able to do a better job!

 

[[40oz]]

Is anyone working on this?

I have it partially working:

Healspash	NOT TESTED
HealGroup     	OK
HealBalance    	OK
HealSelf       	NOT TESTED
HealXtarget    	OK
HealPet        	NOT TESTED
Nuke            OK
Dot             Partially Working (Doesn't seem to cast them often)
Mez             NOT WORKING
Bard            NOT WORKING
Pulling		NOT TESTED
Loot		WORKING
Debuff		Partially Working (Debuffs Kill Target but not Adds)
Buff		COMPLETELY MESSED UP (And I don't know how to fix it)
Rez		OK
SelfBuff	OK
Aura		OK
Endurance	NOT TESTED
MAna		NOT TESTED
Modrod		NOT TESTED
Merc		NOT TESTED
FD		NOT TESTED
Cure		NOT TESTED
MT Buff		OK
AA		OK
Fade		NOT TESTED
Lifetap		NOT TESTED
Jolt		NOT TESTED
Snare		NOT TESTED
Root		NOT TESTED
Clicky Nuke	OK
ImHit		OK

Other Stuff:
*There is something wrong with Clear target events (they don't work at all)
*I haven't tested /mac bot40 load (no idea what will happen)
*I found that some features just never worked properly die to typos/undelcared variables (such as Interrupt to heal).


I'm not a programmer, so some of the "fixes" are probably very poor. Am happy to work with others on getting it fixed, but I'm sure that someone who knows what they are doing will be able to do a better job!

Thanks Poly.

Did you start from the ones I posted a few posts back? If so I can diff the files and evaluate your changes.

I won't have solid time to work on more fixes until next week, but if I can review others changes to speed things up I will find some time. I should have a little bit of time when I get home tonight

 

[poly]

Is anyone working on this?

I have it partially working:

Healspash	NOT TESTED
HealGroup     	OK
HealBalance    	OK
HealSelf       	NOT TESTED
HealXtarget    	OK
HealPet        	NOT TESTED
Nuke            OK
Dot             Partially Working (Doesn't seem to cast them often)
Mez             NOT WORKING
Bard            NOT WORKING
Pulling		NOT TESTED
Loot		WORKING
Debuff		Partially Working (Debuffs Kill Target but not Adds)
Buff		COMPLETELY MESSED UP (And I don't know how to fix it)
Rez		OK
SelfBuff	OK
Aura		OK
Endurance	NOT TESTED
MAna		NOT TESTED
Modrod		NOT TESTED
Merc		NOT TESTED
FD		NOT TESTED
Cure		NOT TESTED
MT Buff		OK
AA		OK
Fade		NOT TESTED
Lifetap		NOT TESTED
Jolt		NOT TESTED
Snare		NOT TESTED
Root		NOT TESTED
Clicky Nuke	OK
ImHit		OK

Other Stuff:
*There is something wrong with Clear target events (they don't work at all)
*I haven't tested /mac bot40 load (no idea what will happen)
*I found that some features just never worked properly die to typos/undelcared variables (such as Interrupt to heal).


I'm not a programmer, so some of the "fixes" are probably very poor. Am happy to work with others on getting it fixed, but I'm sure that someone who knows what they are doing will be able to do a better job!

Thanks Poly.

Did you start from the ones I posted a few posts back? If so I can diff the files and evaluate your changes.

I won't have solid time to work on more fixes until next week, but if I can review others changes to speed things up I will find some time. I should have a little bit of time when I get home tonight

Yes, I started with the one you posted a few pages back. I didn't comment much, and my programming experience is basically 1 semester of FORTRAN in a Civil Engineering undergrad course. At the very least, you can probably do a compare of my changes with your version and quickly see WHAT needs to be fixed, then do it properly (i.e. better than me)!

PM me or ask here if you wanna know why I did something (can skype too if you want, I'm East coast Australia, so only 1 hour time difference with you if you are in Japan).

 

[Nightmare327]

Poly: I noticed one of the major changes you made was changing the references to MyIni to the explicitly referenced INI file name? Was this because of an issue? I was trying to figure out which version to start working with, and the compare showed that on a ton of lines, so I was trying to understand the change. I am not complaining, so do not take the comment as that, just wanting to make sure I understand why the change was made.

<CODE>
/declare DebugLevel int outer ${Ini[MyIni,Settings,DebugLevel,0]}

to

/declare DebugLevel int outer ${Ini[Bot_${Me.CleanName}_${MacroQuest.Server}_${Me.Class}.ini,Settings,DebugLevel,2]}
</CODE>

 

[Nightmare327]

Here are some more fixes to bot40.mac. I started with Poly's version of 40oz's version

Most of my changes were startup issues. I have not had a chance to run it during a fight yet.

I added a comment into the changes section to mark the sections I updated. Now to head off to work.

 

[Nightmare327]

Also Fry, I noticed the version of bot.mac included in the latest mmoloader updates is based on an older version of 40oz's version (from January 2017 I think). I know I am comfortable with all of my changes going into the compile version (as few as they are), as long as everyone else is also. Just thinking you may wish to update to a newer version if you can.

 

[poly]

Poly: I noticed one of the major changes you made was changing the references to MyIni to the explicitly referenced INI file name? Was this because of an issue? I was trying to figure out which version to start working with, and the compare showed that on a ton of lines, so I was trying to understand the change. I am not complaining, so do not take the comment as that, just wanting to make sure I understand why the change was made.

<CODE>
/declare DebugLevel int outer ${Ini[MyIni,Settings,DebugLevel,0]}

to

/declare DebugLevel int outer ${Ini[Bot_${Me.CleanName}_${MacroQuest.Server}_${Me.Class}.ini,Settings,DebugLevel,2]}
</CODE>

Yeah, I done that as a temp thing, cause I was having trouble getting sub spellload2 to read values from the INI, they were all being read as NULL or default values. When I hard-coded the ini name, it seemed to work for me. You can easy change them back with replace all (I'm using notepad++ with the MQ2 language file someone posted a few days back).

I never got as far as testing if there was the same issue with the mob_ignore_list.ini..... but loot.ini seemed to work fine. So I dunno..... it might have been something else that I changed that fixed the issues in spellload2, I would say you might try to change them back and see what happens

Anyway, I'm due to have a baby next week, so not sure how much more I can help with fixing this

 

[poly]

Oh, almost forgot, in combat, on healers, it thinks that PCs on xtarget are adds.... I STILL can't figure out why

 

[Fry]

Also Fry, I noticed the version of bot.mac included in the latest mmoloader updates is based on an older version of 40oz's version (from January 2017 I think). I know I am comfortable with all of my changes going into the compile version (as few as they are), as long as everyone else is also. Just thinking you may wish to update to a newer version if you can.

MMOLoader wont update a macro if it's already there, only fresh download of zip will get it. We did this so it doesn't overwrite peoples macro changes.

That said, I haven't updated it in quite awhile. Once things are a little more stable I'll get it done.

 

[Chatwiththisname]

Oh, almost forgot, in combat, on healers, it thinks that PCs on xtarget are adds.... I STILL can't figure out why

My guess is that the macro itself only checks the array of ${XTarget[Index].ID} for a value and if there is one then it is considered you have an Add. Unless this is recent it was likely coded in this way. I did the same thing in my Pull.mac, changing this would require a comparison to group Member ID for each Xtarget, which is another nested for loop in an already complicated program. I believe that would be considered an "added feature" which is not likely a priority at the moment.

Finding the sub that checks for adds and altering it directly would likely be your best bet. If you always use XTarget[1] for your PC holding location then altering the sub range to be between 2 and whatever value would fix that issue. If you're adding multiples adjust accordingly. iirc macros are a index starts at 1 logic as opposed to index starts at 0 logic.

 

[William12]

Oh, almost forgot, in combat, on healers, it thinks that PCs on xtarget are adds.... I STILL can't figure out why

My guess is that the macro itself only checks the array of ${XTarget[Index].ID} for a value and if there is one then it is considered you have an Add. Unless this is recent it was likely coded in this way. I did the same thing in my Pull.mac, changing this would require a comparison to group Member ID for each Xtarget, which is another nested for loop in an already complicated program. I believe that would be considered an "added feature" which is not likely a priority at the moment.

Finding the sub that checks for adds and altering it directly would likely be your best bet. If you always use XTarget[1] for your PC holding location then altering the sub range to be between 2 and whatever value would fix that issue. If you're adding multiples adjust accordingly. iirc macros are a index starts at 1 logic as opposed to index starts at 0 logic.

Why not have it check xtarget for PC or NPC ? Im sure it already checks xtarget for health/id etc. ${Me.XTarget[1].Type.Equal[NPC]}

 

[Nightmare327]

That makes sense then, it happened because I had just cleaned out my Macros directory to make sure all of the ones I use would work. I planned on adding them back from the Unchecked folder one at a time

MMOLoader wont update a macro if it's already there, only fresh download of zip will get it. We did this so it doesn't overwrite peoples macro changes.

That said, I haven't updated it in quite awhile. Once things are a little more stable I'll get it done.

 

[poly]

Oh, almost forgot, in combat, on healers, it thinks that PCs on xtarget are adds.... I STILL can't figure out why

My guess is that the macro itself only checks the array of ${XTarget[Index].ID} for a value and if there is one then it is considered you have an Add. Unless this is recent it was likely coded in this way. I did the same thing in my Pull.mac, changing this would require a comparison to group Member ID for each Xtarget, which is another nested for loop in an already complicated program. I believe that would be considered an "added feature" which is not likely a priority at the moment.

Finding the sub that checks for adds and altering it directly would likely be your best bet. If you always use XTarget[1] for your PC holding location then altering the sub range to be between 2 and whatever value would fix that issue. If you're adding multiples adjust accordingly. iirc macros are a index starts at 1 logic as opposed to index starts at 0 logic.

This is new... it didn't do this before last patch.... I mentioned this a few posts back

It has checks for on each xtarget already to see if they are npcs or not.... its just not workin right now. Its not an added feature, as without it working properly mez and other cc things will not work.

 

[queequeg0]

There is a bug in the pulling string. I haven't been able to solve it yet but the character will run out to pull but as soon as it aggros a mob, the toon turns around as if to run back and then just stands there. If I come up with a fix, I will post it.

 

[poly]

There is a bug in the pulling string. I haven't been able to solve it yet but the character will run out to pull but as soon as it aggros a mob, the toon turns around as if to run back and then just stands there. If I come up with a fix, I will post it.

Running the new macro code? I've not had a chance to test pulling yet.