Dev's Bot - a potential problem.

I would advise the 5-6 people still using his bots to try to just learn another all class macro, and move away from his, as asking for support you are going to be shit out of luck anyways - whether its now or 3 months from now or a year from now.

Speaking as a person who initially just bought 4 of Dev's macro's and then bought the full package, and then the full package again to get support from Dev, I can say that the bot40 macro does better dps, does better mezing, does better buffing, does better debuffing than Dev's macros ever did with the exception of the magebot2 macro performs much better than bot40, so I will be happy whenever it is that bot40 is back up and running.


My only gripe with those other ones are the lack of multiple pull path support and not all offer custom ini setups you can do with your toon to have various configurations, but that isn't worth not changing over to something else.

The best part is there is a 5 page thread on bot40 ini's that can be used and updated and perform great. About the only class I have not used bot40 on is druid (simply because in the alts I have I do not really play a druid)

But I for one am not going to suggest one way or another what Chat should be doing, I am just happy that someone and in this case it is Chat is doing something because I am sure there are alot of people like myself who have zero coding ability.


I know its tough to change when you have become so reliable on those bots, but I'm so happy I decided to try out some other macros out there. Remember there is modbot, core.mac, automacros and KA to choose from as well bot.mac all of which perform so much faster in response times. Especially with healing routines.
 
Last edited:
I understand that Bot40 is a great mac but it is currently not working. I'm just used to the Dev ones as I am familiar how to update INI files. These new ones I am not sure how to get to work and when I see an error I am not familiar with how to fix it. Kiss Assist only works with MQ2 though or is there an MMO bugs version of KA? from what I understand KA users some plugins that mmo does not use in their compile?

I could be wrong. If someone has a working INI file for a shaman in the above macro's I would be willing to try it out. Just looking for a starting point INI so I can see what spells I need to change.

Thanks Deth
 
I lot of the problem with all of these macros is that they are beyond my personal ability (I know it doesn't seem that way as often as I put out updates when I'm actively working on something). Truth be told, working on the bot40 and dev macros have been rather eye opening for me. A lot of the methods they use were foreign to me. For instance, I never consider creating a string variable that had multiple conditions in them. IE:
Code:
/noparse /declare CanCastOnMob string outer (${Target.LineOfSight} && ((${Target.Distance}<=${Spell[${${CurrentSub}SpellName${i}}].AERange}||${Target.Distance}<=${Spell[${${CurrentSub}SpellName${i}}].Range}||${Target.Distance}<=${Me.AltAbility[${${CurrentSub}SpellName${i}}].Spell.AERange}||${Target.Distance}<=${Me.AltAbility[${${CurrentSub}SpellName${i}}].Spell.Range}||${Target.Distance}<=${FindItem[${${CurrentSub}SpellName${i}}].Spell.Range})||${Spell[${${CurrentSub}SpellName${i}}].SpellType.NotEqual[detrimental]} && ${FindItem[${${CurrentSub}SpellName${i}}].Spell.SpellType.NotEqual[detrimental]}))

That's a really long and complicated if statement. But by declaring it as a string that isn't parsed it can be used in a lot simpler manner by simply typing

Code:
/if (${CanCastOnMob}) /dothethingIwant

Sure beats typing that whole string out every time I want to see if I can cast on a mob.

Additionally, having loading subs and subs seperate, I can /varset CurrentSub Lifetap
/if (!${Defined[${CurrentSub}Loaded]}) /declare ${CurrentSub}Loaded bool outer FALSE
/if (!${${CurrentSub}Loaded}) /call ${CurrentSub}Load

then in Sub Lifetap I could do all my declares/pull all the information from the INI and create INI entries if they aren't present.

which is exactly how it is done in Bot40.mac with some caveats, that some things aren't working as intended because of the update.

I'm not really programming this macro so much as I am learning the structure of the macro and applying my understanding of the major changes that broke it to the existing code.

Now, having learned a lot from looking at PeteSampras's code I could probably go on to make something myself that would likely be a useful macro to automate playing a character. One of my issues is that I dislike the way arrays are done in macros and in some cases I don't understand how they were declared or what the intention was when declaring them so I end up rewriting entire subs.

In the long run this is a learning experience for me and you, the users, are benefiting from it regardless of which macro I choose to work on. I don't play EQ. At least, not with any intention of progressing characters. I've "Played" EQ a lot lately, but every last point of EXP was attained from a macro I've worked on. At this point it totals to about 370 levels worth of EXP across all the characters I've made testing them. It'll probably be a lot more before things work correctly. I'm about to get on and start trying to work on the issues that people have messaged me about in hopes of fixing them and getting things moving a bit better. Luckily dev did work quite a bit on his own macros prior to becoming MIA after the updates. So I at least have a leg up on that.
 
Working on debugging the debuff subs. Currently I've found a possible typo in the sub where it does a check

Code:
/if (${1TargCount}>=${debuffMinMobs[${dArray}]} && ${lTargCount}<=${debuffMaxMobs[${dArray}]}) {

where ${1TargCount} appears to be a typo. However, checking "${TargCount} also returns an undeclared variable. Then also there is |TargCount which I would have to check out.

Lots of debugging script added trying to track down issues for casting Heals (Fixed the issue that was causing it to say it couldn't find subroutine -targetid|${Target.ID} because the /call CastHeal wasn't using the last parameter, which I set to NULL there was no variable present as that was the intended input for that parameter.

Once I have something that actually moves forward (fixing the debuff subroutine) I'll post an update. At this time I have nothing. Still working on it though.
 
Don't think 1TargetCount is a typo, its a TLO he uses I think. Should be declaration somewhere cause when I asked about a condition a few years back he said to use that to count number of mobs i wanted to check for.


Here is one of those conditions I used for it:

If[(${namedCount} || ${lTargCount} >= 3) && !${Me.Buff[Fury of Ro XIII].ID} ,TRUE,FALSE]


That's a ONE in front of the Targ, the font is different on the forums so looks like a |
 
Last edited:
Don't think 1TargetCount is a typo, its a TLO he uses I think. Should be declaration somewhere cause when I asked about a condition a few years back he said to use that to count number of mobs i wanted to check for.


Here is one of those conditions I used for it:

If[(${namedCount} || ${lTargCount} >= 3) && !${Me.Buff[Fury of Ro XIII].ID} ,TRUE,FALSE]


That's a ONE in front of the Targ, the font is different on the forums so looks like a |

Yeah I found it, it was actually a lowercase L. It was a valid arguement. I've been stepping through the debuff sub one step at a time. At this point I've changed a comparison check to get into the call for debuff and now I"m dealing with undefined variables for two checks for slot.
Code:
/if (${debuffSlot[${debuffNum}].Equal[Item]} && ${FindItem[${debuffSpells[${debuffNum}]}].Timer}) /return
	/if (${debuffSlot[${debuffNum}].Equal[alt]} && !${Me.AltAbilityReady[${debuffSpells[${debuffNum}]}]}) /return

where ${debuffSlot[]} isn't a defined array. I'm in the Load Debuff portion now trying to find the appropriate place to declare it. I assume it'll be coming from the INI Entry for DebuffSpellSlot1=gem7 where it's looking for gem7 to actually be item or alt to back out of the sub. Though I don't know that a return out of the debuff sub is the appropriate action. I Feel like it should instead /alt act or /itemnotify, but I'll get there when I get there. Right now I just want it to cast the debuff.

I do find that /call GetINISetting ${iniName} Debuffs DebuffSpellSlot${nArray} debuffSpellSlot[${nArray}] gem1 is where it should go into the GetINISetting sub to declare all the information. But for some reason it's not being defined. So I'll find the right place to declare it and add it.

Once I get debuff spells sorted I"ll move forward in tracking down other issues.
 
Last edited:
Okay, I fixed the debuff sub best I can tell. It's now casting my walking sleep spell.

Apparently the issue was debuffSlot was supposed to be debuffSpellSlot....so that was the typo I had been looking for. Eureka!

Suppose it is also worth mentioning that I also turned off the Debug by setting it to 0 in devCommonPremium.inc and I changed the way Aura's are handled to fix the spammed error about Aura member not having .Name

Not sure if anyone ran into the aura issue or not but I did so I fixed it.
 
Last edited:
I will test it out tomorrow. Thanks Chat for all your hard work cant wait for this one to work. Once this one is down I'm sure the rest will be easier to figure out. MQ2Bot is nice for dps but not so much utility. The thing flies through mana on my mage.

Hope you have a great thanksgiving.

Deth
 
Chat,

fired it up this morning in PoK only real quick before work and no eerors came up. Only issue was it made me unsuspend my merc. I will look at the INI later to see how to turn that off. Will test it further tonight.

Thanks again for your hard work.

Deth
 
Chat,

fired it up this morning in PoK only real quick before work and no eerors came up. Only issue was it made me unsuspend my merc. I will look at the INI later to see how to turn that off. Will test it further tonight.

Thanks again for your hard work.

Deth

[MercSettings]
BurnPct=0
ManageMerc=FALSE
OutOfCombatStance=NULL
InCombatStance=NULL
MercAssistPct=FALSE
AssistPct=97

When there is no manual....check your settings :)

Fixing errors during idle is easy stuff. It's finding all those special cases that causes the macro to try to do something that tends to be the issue with rewriting things to find undeclared variables. #warning is still in the code. So it'll still pause if it finds one. Again, you can remove the #warning but I won't know about variables that aren't defined.

Due to the way parameters are handled (they are just blank if no value is passed to them) some checks may not evaluate correctly causing some things to not work as they should. If this occurs, let me know what specific feature isn't working and I can look into debugging it.
 
Last edited:
2 of 3 corrections made. The last one is a bit confusing to me. I see on line 5777 where it says that rType is an undefined variable. The problem with that is that rType is a parameter and should be defined by the call to it. Since it is an event, it is called automatically while doing events. IE: /doevents

It should then find the information from within a chatbox and then call the event. Other then that I have the following corrections. Having looked at the event for it, it appears that it only has #1# and #2#, but there appears to be 4 parameters.

Code:
[2017/11/23 19:22:07] WARNING: Undefined Variable rType used on line 5777@devCommonPremium.inc /if (${rType.Equal[NULL]}) /varset rType TELL

Code:
#event rTell "#1# tells you, '#2#'"
#event rTell "#1# told you, '#2#'"

Code:
Sub Event_rTell(rLine,string rFrom,string rMsg, string rType)

So I can see that #1# should be the person who sent you a message, #2# should be the rMsg, but how they were supposed to determine the "Type" is beyond me. I haven't worked with events really and thus this one leaves me a bit confused. I added

Code:
	/if (!${Defined[rType]}) /declare rType string outer TELL

defined check in hopes of it correcting the issue. Though I can't say I understand it.

Added a check for Plugin MQ2Nav and force it to load at the start of the macro if it isn't found to avoid undeclared variable "Navigation". Placed the check in DevCommonPremium.inc



Code:
[2017/11/23 18:43:27] WARNING: Undefined Variable gArray used on line 658@shamanbot.mac /if (${healClasses[${hInt}].Find[${Group.Member[${grpArray}].Class.ShortName}]} || ${healClasses[${hInt}].Find[${Group.Member[${grpArray}].Class.Name}]} || ${healClasses[${hInt}].Find[${Group.Member[${grpArray}].CleanName}]} || ((${healClasses[${hInt}].Find[mt]} || ${healClasses[${hInt}].Find[maintank]}) && (${Group.Member[${gArray}].MainTank} || ${Group.Member[${gArray}].CleanName.Equal[${mainTank}]}))) {Macro Paused.

where gArray was supposed to be grpArray corrected in Shamanbot.mac
 
Last edited:
Was gone the last week and just saw this.
I have a well set up ini that works well so I figured I would test it out with the changes you made.

I copied all files form this thread with updated bugs compile.

The macro tries to load now, it didn't before. but I keep getting the same issue.

"The version of devMovement.inc v1.74 is not supported by shamanBot.mac v2.25, please download a newer version of devMovement.inc"

I would be very willing to help out, just let me know what is needed.

Thanks
 
Was gone the last week and just saw this.
I have a well set up ini that works well so I figured I would test it out with the changes you made.

I copied all files form this thread with updated bugs compile.

The macro tries to load now, it didn't before. but I keep getting the same issue.

"The version of devMovement.inc v1.74 is not supported by shamanBot.mac v2.25, please download a newer version of devMovement.inc"

I would be very willing to help out, just let me know what is needed.

Thanks


Work your way back in the thread till you find the one with the DevMovement I put out, it's the updated version.
 
With MQ2Nav not loaded before starting the bot, the .ini loads then I receive a warning:

WARNING: Undefined Variable Navigation used on line 3551@devCommonPremium.inc ... /if (${Navigation}) {
macro paused

With MQ2Nav loaded before starting the bot, I receive an error then the .ini loads and tries to cast a buff then I receive a warning:

error
No such "plugin" member "NotEqual"
devCommonPremium.inc@138 (Commonlnit): /if (${Plugin{MQ2Nav].NotEqual[MQ2Nav]}) {
shamanbot.mac@140 (main(string ininameStr)): /call Commonlnit

WARNING: Undefined Variable Twist used on line 1465@devCommonPremium.inc... /if (${Me.Casting.ID} && (${Me.Casting.Skill.Find[Instrument]} || ${Me.Casting.Skill.Find[Sing]} || ${Twist.Twisting})) {
macro paused
 
Last edited:
With MQ2Nav not loaded before starting the bot, the .ini loads then I receive a warning:

WARNING: Undefined Variable Navigation used on line 3551@devCommonPremium.inc ... /if (${Navigation}) {
macro paused

With MQ2Nav loaded before starting the bot, I receive an error then the .ini loads and tries to cast a buff then I receive a warning:

error
No such "plugin" member "NotEqual"
devCommonPremium.inc@138 (Commonlnit): /if (${Plugin{MQ2Nav].NotEqual[MQ2Nav]}) {
shamanbot.mac@140 (main(string ininameStr)): /call Commonlnit

WARNING: Undefined Variable Twist used on line 1465@devCommonPremium.inc... /if (${Me.Casting.ID} && (${Me.Casting.Skill.Find[Instrument]} || ${Me.Casting.Skill.Find[Sing]} || ${Twist.Twisting})) {
macro paused


I neglected to test that the check for it worked correctly. My bad. :)

Was supposed to be ${Plugin[MQ2Nav].Name.NotEqual[MQ2Nav]}

I'll change it and try again lol.
 
Last edited:
This should correct that issue. Thanks for letting me know.
 
Last edited:
That fixed the Nav problem.

Next hiccup is when trying to cast buff.

WARNING: Undefined Variable Twist used on line 1465@devCommonPremium.inc... /if (${Me.Casting.ID} && (${Me.Casting.Skill.Find[Instrument]} || ${Me.Casting.Skill.Find[Sing]} || ${Twist.Twisting})) {
macro paused
 
That fixed the Nav problem.

Next hiccup is when trying to cast buff.

WARNING: Undefined Variable Twist used on line 1465@devCommonPremium.inc... /if (${Me.Casting.ID} && (${Me.Casting.Skill.Find[Instrument]} || ${Me.Casting.Skill.Find[Sing]} || ${Twist.Twisting})) {
macro paused

/plugin mq2twist

Added a check for that one as well to autoload it.
 
Last edited:
Next set of test results.

Not sure at what point of loading the bot the .ini is being changed.

1-
Any groupbuff set to false is changed to true-
ex GroupBuffAuto1=TRUE

Any debuff set to false is changed to true-
ex DebuffEnabled4=TRUE

These 2 issues can be worked around by removing the buff or debuff in the .ini, multiple ini's would be required. Problem with this is in the current form the bot will only recognize a no named .ini

From the bot:
shamanBotSettings.ini (you can create custom INIs naming them shamanBotSettings_name.ini

Next - When doing group buffs it only does 1 buff per cycle instead of all buffs consecutively while doing the buff check.

OK, last but not least, not sure if this is a chicken or an egg kind of situation or not.
Once mob is engaged the bot goes through all debuffs, then gets stuck in a debuff loop. Just casting the debuffs over and over, not moving onto the combat spells. Here is the chicken/egg thing, ALL combat spells in the ini. are changed to require GOM to fire.
ex SpellGOM1=TRUE

That is all for now, thanks again for all the help getting this far.