Dev's Bot - a potential problem.

[Chatwiththisname]

If you are interested in donating to me directly for my efforts you can donate here. Reward ChatWithThisName directly!

Classes I've Worked on:
Bard
Berserker
Enchanter
Shaman
Shadow Knight

I still need testing for all classes and any information you can provide towards fixing these once premium pay to use bots would be greatly appreciated.

What you will need:

classbot.mac (IE: Skbot2.mac, shamanbot.mac, bardbot.mac, etc etc)
classbotsettings.ini
DevCommonPremium.inc
devMovementPremium.inc
devCast.inc
devPull.inc
devLoot.inc

How to use this:

Once you've downloaded the bot matching your class type

/mac classbot
or
/mac classbot custom

where custom is the name of the custom ini you will use.

/if you type /mac classbot it will use the default ini classbotsettings.ini
If you type /mac classbot custom then it will generate a classbotsettings_custom.ini

For classes I haven't worked on. If you don't supply a custom ini name as a parameter it will use classbotsettings_.ini this is a known defect. But for the ones that do that I have not made it around to them to get them running and don't want to just throw out a blanket fix as it doesn't hurt functionality much.

If you encounter an issue with the macros let me know. I hope to get these going for everyone.


Bot on this post.
Bard
Beastlord
Berserker
Cleric
Druid

 

[Chatwiththisname]

Uploads Continued~~

Bots on this post.
Enchanter
Mage
Monk
Necro
Paladin
Ranger
Rogue

 

[dewey2461]

I've found a couple instances where eqMule has changed the return type of some functions from NULL to "".

What is the function passing in as invalidRepsponse ?

 

[Chatwiththisname]

Uploads continued~~

Bots on this post.
Shaman
Shadow Knight
Warrior
Wizard

 

[Chatwiththisname]

I've found a couple instances where eqMule has changed the return type of some functions from NULL to "".

What is the function passing in as invalidRepsponse ?

Yes, EQMule said that if the parameter isn't used then it should return NULL, however that is not the case, it is simply a blank. Thus any parameters should not be checking for NULL, but instead should be a bool wrapper to check it for a value.

 

[Chatwiththisname]

/if (!${Bool[${iniNameStr}]} || ${iniNameStr.Equal[default]}) {
		/varset iniName shamanBotSettings.ini
		/echo ${iniName} is the name of INI. 
	} else {
		/varset iniName shamanBotSettings_${iniNameStr}.ini
		/echo ${iniName} is the name of INI. 
	}

was changed from

/if (${iniNameStr} || ${iniNameStr.Equal[default]}) {
		/varset iniName shamanBotSettings.ini
		/echo ${iniName} is the name of INI. 
	} else {
		/varset iniName shamanBotSettings_${iniNameStr}.ini
		/echo ${iniName} is the name of INI. 
	}

to fix the loading of the default INI if no ini is used. IE: /mac shamanbot

IniNameStr was returning as you said "" which was causing it to try and load an INI shamanbot_.ini instead of shamanbot.ini

 

[Chatwiththisname]

Once I fixed that it blew through the loading process without an issue.

Then I run into an unknown command in Sub EchoLog. My guess is /myEcho is the unrecognized command. Looking for the alias declaration now.

I added more checks and debug script information.

[11/20/2017 18:19:12] Global Command: DBG3: | DBG3: GetINISetting entered
[11/20/2017 18:19:12] DBG3: SendTell entered
[11/20/2017 18:19:12] DBG3: EchoLog entered
[11/20/2017 18:19:12] DBG3: StripText entered
[11/20/2017 18:19:12] Command not recognized rTellB
[11/20/2017 18:19:12] DBG3: Event_MQ2Cmd entered
[11/20/2017 18:19:12] DBG3: Event_rTell entered
[11/20/2017 18:19:12] DBG3: GlobalCommands entered
[11/20/2017 18:19:12] DBG3: EchoLog entered
[11/20/2017 18:19:12] DBG3: StripText entered
[11/20/2017 18:19:12] Global Command: DBG3: | DBG3: GetINISetting entered
[11/20/2017 18:19:12] DBG3: SendTell entered
[11/20/2017 18:19:12] DBG3: EchoLog entered
[11/20/2017 18:19:12] DBG3: StripText entered
[11/20/2017 18:19:12] Command not recognized rTellB
[11/20/2017 18:19:12] DBG3: Event_MQ2Cmd entered
[11/20/2017 18:19:12] DBG3: Event_rTell entered
[11/20/2017 18:19:12] DBG3: SafePC entered
[11/20/2017 18:19:12] DBG3: Event_MQ2Cmd entered
[11/20/2017 18:19:12] DBG3: Event_rTell entered

From my log I get that. where I added rTellB to the end of a line in the following sub.

Sub Event_rTell(rLine,string rFrom,string rMsg, string rType)
	/varset CurrentSub Event_rTell
	/call Debug 3 "${CurrentSub} entered"
	/declare risSafe bool local
	/declare rnum int local
	/declare hCommand	string local
	/declare hDoes		string local
	/declare hMsg		string local
	/declare rFromID	int local 0
	/declare rFromEQBC	bool local FALSE
	/if (${rType.Equal[NULL]}) /varset rType TELL
	
	/if (${rFrom.Equal[${Me.Pet.CleanName}]}) /return
	/if (${rType.Equal[TELL]} && !${tellCommands}) /return
	/if (${rMsg.Find[Command not recognized]}) /return
	
	/if (${rFrom.NotEqual[MQ2]}) {
		/if (${rFrom.Left[6].Equal[(EQBC)]}) {
			/varset risSafe TRUE
			/varset rFromEQBC TRUE
			/varset rFrom ${rFrom.Right[-6]}
			/varset rFromID ${Spawn[pc ${rFrom}].ID}
		} else {
			/if (${rFrom.Left[1].Compare[ ]} < 0) /varset rFrom ${rFrom.Right[-2].Left[-1]}
			/if (${rType.Equal[TELL]}) {
				/call EchoLog "\au${Time} \aoReceived a tell from \ag${rFrom} \aosaying: \ay${rMsg}"
				/if (${relayTells} && ${relayTarget.Left[1].Equal[/]}) /docommand ${relayTarget} >> [Tell]  ${rFrom}: '${rMsg}'
			}			
			/varset rFromID ${Spawn[pc ${rFrom}].ID}
			/call SafePC ${rFrom}
			/varset risSafe ${Macro.Return}
		}
	} else {
		/varset risSafe TRUE
	}

	/if (${risSafe}) {
		/if (${rMsg.Left[12].Equal[MISSIONCOMM ]} && ${missionMode}) {
			/call MissionCommandHandler ${rFrom} "${rMsg}" ${rFromEQBC}
			/if (${Macro.Return.NotEqual[COMPLETED_NOTFOUND]}) {
				/if (${Macro.Return.Equal[ABORT_SYNTAX]}) {
					/varset hMsg \ayYour command could not be completed due to improper syntax
				} else /if (${Macro.Return.Equal[COMPLETED_SUCCESS]}) {
					/varset hMsg \agYour command was completed successfully.
				} else {
					/varset hMsg \ag${Macro.Return}
				}
			} else {
				/varset hMsg \ayMission command not recognized rTellA
			}
		}	else {
			/call BotCommands ${rFrom} "${rMsg}" ${rFromEQBC}
			/if (${Macro.Return.NotEqual[COMPLETED_NOTFOUND]}) {
				/if (${Macro.Return.Equal[ABORT_SYNTAX]}) {
					/varset hMsg \ayYour command could not be completed due to improper syntax
				} else /if (${Macro.Return.Equal[COMPLETED_SUCCESS]}) {
					/varset hMsg \agYour command was completed successfully.
				} else {
					/varset hMsg \ag${Macro.Return}
				}
			} else {
				/call GlobalCommands ${rFrom} "${rMsg}" ${rFromEQBC}
				/if (${Macro.Return.NotEqual[COMPLETED_NOTFOUND]}) {
					/if (${Macro.Return.Equal[ABORT_SYNTAX]}) {
						/varset hMsg \ayYour command could not be completed due to improper syntax
					} else /if (${Macro.Return.Equal[COMPLETED_SUCCESS]}) {
						/varset hMsg \agYour command was completed successfully.
					} else {
						/varset hMsg \ag${Macro.Return}
					}
				} else {
					/varset hMsg \ayCommand not recognized rTellB
				}	
			}
		}
		/if (${hMsg.NotEqual[NULL]}) {
			/if (${rFromEQBC}) /varset rFrom (EQBC)${rFrom}
			/if (${rType.NotEqual[Group]}) /call SendTell ${rFrom} "${hMsg}"
		}
	}
/return

 

[Chatwiththisname]

found the issue. It was actually in Event_MQ2Cmd which was triggering Event_rTell

 

[Chatwiththisname]

Someone with a good shaman ini wanna try this for me?

 

[Crippie]

just fired up an old ini I had getting :

WARNING: Undefined Variable healRecastTimer1 used on line 735@shamanbot.mac /if (${Defined[healRecastTimer${hInt}]} && ${healRecastTimer${hInt}}) /next hIntMacro Paused.

not sure if it's my ini or not

 

[Chatwiththisname]

just fired up an old ini I had getting :

WARNING: Undefined Variable healRecastTimer1 used on line 735@shamanbot.mac /if (${Defined[healRecastTimer${hInt}]} && ${healRecastTimer${hInt}}) /next hIntMacro Paused.

not sure if it's my ini or not

Nah, MQ2 Reads the entire line of code, so it checked to see if the variable was defined and used the variable on the same line, the first check for it to be defined was fine, but it shouldn't also be used in the event it isn't defined.

/if (${Defined[healRecastTimer${hInt}]}) {
    /if (${healRecastTimer${hInt}}) /next hInt
}

is the way it should be done when checking if something is defined. I'll try to find places where the incorrect method is used and try to correct it. Thanks for the information.

I think a bigger problem is that there are multiple /next var's for a single for loop. Such as hInt, where it should be /continue instead of /next hInt on that line and a whole lot following it.

 

[Chatwiththisname]

Ok, so I can verify that the shamanbot.mac is now casting a group buff and using a heal spell (my shaman is only 36) as per my INI. It is however not casting my slow (walking sleep). Not sure if it is related to my INI or not as I'm not familiar with the macro. (I know that sounds silly because I'm fixing it, but I really don't know much about it.)

Believe these are the only ones I have updated code on. (Lots of different files ugh.)

Please try it out and let me know what your results are.

NOTE!: I've left Debug set to 3. You WILL GET SPAMMED with lots of red words. This is going to help me find the information I need to fix anything that breaks. If everything is running smoothly feel free to open DevCommonPremium.inc and change /declare DebugLevel int outer 3 to /declare DebugLevel int outer 0

If you encounter an undefined variable, please report it to me by going to your Macroquest2/Logs folder and finding shamanbot.mac file and copying it all to a PRIVATE MESSAGE to me. No need to clutter the thread if we can avoid it. Please enclose the log information in CODE tags. I want the log so I can also get my debug information. If you've disabled the debug by changing the level to 0 then I don't need your log file, just put the error in the PM.

As it was with bot40.mac to get the macro to stop pausing on you for undeclared variables you only have to remove the #warning from the files.


Goodnight all!

 

[Carbja23]

No shammy in my bot crew, if you work on bard lmk and I'll definitely test after the holiday.

 

[Dethbrngr]

Yoh Chat,

Thank you soo much for this. I know you did this work because of my request. I will try it out on my 100 shammy.

I can't say thank you enough.

Deth

 

[Dethbrngr]

Ok So I set up an INI file and I try and start it up and I keep getting this error

DBG3"GetINISetting entered DevCommonPremium.inc"

Undefined variable Navigation used on line 3513@devCommonPremium.incn/if (${Navigation})

No clue what that means

 

[okcmagistrate]

Deth,

I believe its from back when Dev was taking care of the bot MQ called to the plugin MQ2Navagation, and that plugin is gone and MQ2Nav has taken its place...

/shrug I could be wrong.

 

[Chatwiththisname]

I've noticed uneven downloads of the files I uploaded. Testing with only some of the updated files will likely not generate a working bot. Just FYI.

 

[Chatwiththisname]

Deth,

I believe its from back when Dev was taking care of the bot MQ called to the plugin MQ2Navagation, and that plugin is gone and MQ2Nav has taken its place...

/shrug I could be wrong.

Navigation TLO is in fact something that requires a plugin to be active. Type /plugin mq2nav
then run the macro and that issue will be fixed.

Alternately I'll add a bit that will fix that error popping up.

/if (${Plugin[MQ2Nav].Name.NotEqual[MQ2Nav]} && !${Defined[Navigation]}) /declare Navigation bool outer FALSE

which will check to see if the plugin is loaded and if Navigation has been defined yet and if not created a boolean (TRUE/FALSE) value accessible from anywhere in the script and make it false. That way any checks for /if (${Navigation}) will return false and thus not run any code in the block.

I'll have to check more into this to find out where I'll put it. But the most likely candidate for that would be in DevCommonPremium.inc as that will affect all of the other Macros on CommonInit which is the very first sub routine that will run once you enter main.

Having added debugging scripting you can see the flow of the script after the first run by setting DebugLevel to 3 and then opening your log file.

[11/21/2017 03:11:40] DBG3: CommonInit entered DevCommonPremium.inc
[11/21/2017 03:11:40] DBG3: EchoLog entered DevCommonPremium.inc
[11/21/2017 03:11:40] DBG3: StripText entered DevCommonPremium.inc
[11/21/2017 03:11:40] Initialized devCommonPremium.inc v3.51 - Written By Devestator - Updated by ChatWithThisName
[11/21/2017 03:11:40] DBG3: MovementInit entered devMovementPremium.inc
[11/21/2017 03:11:40] DBG3: moveLogWrapper entered devMovementPremium.inc
[11/21/2017 03:11:40] DBG3: EchoLog entered DevCommonPremium.inc
[11/21/2017 03:11:40] DBG3: StripText entered DevCommonPremium.inc
[11/21/2017 03:11:40] Initializing devMovementPremium.inc v2.74 - Written By Devestator
[11/21/2017 03:11:40] DBG3: MQ2CastInit entered devCast.inc
[11/21/2017 03:11:40] DBG3: devCastInit entered devCast.inc
[11/21/2017 03:11:40] DBG3: EchoLog entered DevCommonPremium.inc
[11/21/2017 03:11:40] DBG3: StripText entered DevCommonPremium.inc
[11/21/2017 03:11:41] Initializing devCast.inc v1.06
[11/21/2017 03:11:41] DBG3: EchoLog entered DevCommonPremium.inc
[11/21/2017 03:11:41] DBG3: StripText entered DevCommonPremium.inc
[11/21/2017 03:11:41] Loading Bot specific configuration...
[11/21/2017 03:11:41] DBG3: EchoLog entered DevCommonPremium.inc
[11/21/2017 03:11:41] DBG3: StripText entered DevCommonPremium.inc
[11/21/2017 03:11:41] Shamanbot v1.26 Initialized
[11/21/2017 03:11:41] DBG3: EchoLog entered DevCommonPremium.inc

Above is what I've done to setup a readable debug output for me to see. The VERY FIRST LINE [11/21/2017 03:11:40] DBG3: CommonInit entered DevCommonPremium.inc says that according to the DBG3 output that I entered Subroutine called CommonInit and that the Sub is located inside of DevCommonPremium.inc (you may also notice that I was up till 3am working on this lol.)

This way in addition to the information that MQ2 will output, I'll know what sub it was in at the time of the failure, what sub called that sub etc on back. This gives me more insight to track down issues that might be a result of arguments being passed to a /call from another sub routine that calls the one that was in use at the time of the failure. IE:

/call Cast "${castName}" ${castSlot} ${castMaxTryTime} ${castCallRoutine}

is called correctly to an extent. Later in the code you'll find /call ${castCallRoutine} which should actually call a specific routine string, but instead it tries to call the parameter for the sub routine which is feature1, which as it turns out is -targetid|${Target.ID} which is where the bug someone had previously sent me was coming from. I also encountered this issue anytime my shaman casted their heal spell on a group member, immediately following would have this error related to unable to find sub -targetid|100567 where 100567 is a made up Target.ID for my group member that was needing a heal. Simply commenting out the /call ${castCallRoutine} had made it so that the macro continues on it's way and continues to heal without a problem, but may effect other things that I'm unaware of. Until I backtrack to find out why castCallRoutine is actually being assigned feature1's parameter then there isn't much I can do. But with the added debug scripting I'll be able to back track it much easier.

So the more people that provide me log files in a PM (that way if you miss removing a character name you won't have to worry about it being publicly posted) the more information I can extract and use to hunt down issues. While in theory I can also recreate the situations that produce these issues, more people = more production.

 

[aspire2008]

Deth,

I believe its from back when Dev was taking care of the bot MQ called to the plugin MQ2Navagation, and that plugin is gone and MQ2Nav has taken its place...

/shrug I could be wrong.

Navigation TLO is in fact something that requires a plugin to be active. Type /plugin mq2nav
then run the macro and that issue will be fixed.

Alternately I'll add a bit that will fix that error popping up.

/if (${Plugin[MQ2Nav].Name.NotEqual[MQ2Nav]} && !${Defined[Navigation]}) /declare Navigation bool outer FALSE

which will check to see if the plugin is loaded and if Navigation has been defined yet and if not created a boolean (TRUE/FALSE) value accessible from anywhere in the script and make it false. That way any checks for /if (${Navigation}) will return false and thus not run any code in the block.

I'll have to check more into this to find out where I'll put it. But the most likely candidate for that would be in DevCommonPremium.inc as that will affect all of the other Macros on CommonInit which is the very first sub routine that will run once you enter main.

Having added debugging scripting you can see the flow of the script after the first run by setting DebugLevel to 3 and then opening your log file.

[11/21/2017 03:11:40] DBG3: CommonInit entered DevCommonPremium.inc
[11/21/2017 03:11:40] DBG3: EchoLog entered DevCommonPremium.inc
[11/21/2017 03:11:40] DBG3: StripText entered DevCommonPremium.inc
[11/21/2017 03:11:40] Initialized devCommonPremium.inc v3.51 - Written By Devestator - Updated by ChatWithThisName
[11/21/2017 03:11:40] DBG3: MovementInit entered devMovementPremium.inc
[11/21/2017 03:11:40] DBG3: moveLogWrapper entered devMovementPremium.inc
[11/21/2017 03:11:40] DBG3: EchoLog entered DevCommonPremium.inc
[11/21/2017 03:11:40] DBG3: StripText entered DevCommonPremium.inc
[11/21/2017 03:11:40] Initializing devMovementPremium.inc v2.74 - Written By Devestator
[11/21/2017 03:11:40] DBG3: MQ2CastInit entered devCast.inc
[11/21/2017 03:11:40] DBG3: devCastInit entered devCast.inc
[11/21/2017 03:11:40] DBG3: EchoLog entered DevCommonPremium.inc
[11/21/2017 03:11:40] DBG3: StripText entered DevCommonPremium.inc
[11/21/2017 03:11:41] Initializing devCast.inc v1.06
[11/21/2017 03:11:41] DBG3: EchoLog entered DevCommonPremium.inc
[11/21/2017 03:11:41] DBG3: StripText entered DevCommonPremium.inc
[11/21/2017 03:11:41] Loading Bot specific configuration...
[11/21/2017 03:11:41] DBG3: EchoLog entered DevCommonPremium.inc
[11/21/2017 03:11:41] DBG3: StripText entered DevCommonPremium.inc
[11/21/2017 03:11:41] Shamanbot v1.26 Initialized
[11/21/2017 03:11:41] DBG3: EchoLog entered DevCommonPremium.inc

Above is what I've done to setup a readable debug output for me to see. The VERY FIRST LINE [11/21/2017 03:11:40] DBG3: CommonInit entered DevCommonPremium.inc says that according to the DBG3 output that I entered Subroutine called CommonInit and that the Sub is located inside of DevCommonPremium.inc (you may also notice that I was up till 3am working on this lol.)

This way in addition to the information that MQ2 will output, I'll know what sub it was in at the time of the failure, what sub called that sub etc on back. This gives me more insight to track down issues that might be a result of arguments being passed to a /call from another sub routine that calls the one that was in use at the time of the failure. IE:

/call Cast "${castName}" ${castSlot} ${castMaxTryTime} ${castCallRoutine}

is called correctly to an extent. Later in the code you'll find /call ${castCallRoutine} which should actually call a specific routine string, but instead it tries to call the parameter for the sub routine which is feature1, which as it turns out is -targetid|${Target.ID} which is where the bug someone had previously sent me was coming from. I also encountered this issue anytime my shaman casted their heal spell on a group member, immediately following would have this error related to unable to find sub -targetid|100567 where 100567 is a made up Target.ID for my group member that was needing a heal. Simply commenting out the /call ${castCallRoutine} had made it so that the macro continues on it's way and continues to heal without a problem, but may effect other things that I'm unaware of. Until I backtrack to find out why castCallRoutine is actually being assigned feature1's parameter then there isn't much I can do. But with the added debug scripting I'll be able to back track it much easier.

So the more people that provide me log files in a PM (that way if you miss removing a character name you won't have to worry about it being publicly posted) the more information I can extract and use to hunt down issues. While in theory I can also recreate the situations that produce these issues, more people = more production.

I don't use his bots anymore, but can run some of my old ini's to test something if you need. Frankly, the only thing that is lacking from other macros out there vs Dev's is the multiple pull paths routine & custom ini for the same toon, since it supports multiple pull paths and custom ini files. It just seems like its a lot of work for you to go through all 16 macro files (since there will be undeclared variables in each file, etc) when bot.mac is already one your pet projects lol. Could just strip his pull code and incorporate it into bot.mac to save time.
Since what I hear from others about bot.mac does everything dev's macros does except for those 2 things. Also, I've been told Dev's code is bloated and old with all the changes mq2 has gone through over the years and he really didn't keep up with the changes.

Regarding the mq2Nav/Navigation replacement, I tried the solution you posted plus replacing all references of mq2Navigation to mq2Nav in all the mac and include files about 9-12 months ago. Think I even went as far as look at all the mq2Nav commands and check if they matched with the mq2Navigation commands and TLO's That didn't really help switching over to mq2Nav, it worked well going out to pull but there was some issue with returning back to camp from the pull.

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.

 

[okcmagistrate]

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.

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.