Problem with macros from macros

[sc0ttr0]

I have several small macros that based on chat text launch a different macro.

Since the patch last week, this completely freezes the EQ session. Others in guild that use the mmo compile experience similar issues. People using the other compile do not. I've set up a couple simple macs to duplicate the issue.


Testmac1

#Chat gsay
#Chat guild
#Chat raid


#Event testevent "#*#testline1#*#"

Sub Main
/echo test macro is running
	:loop
		/doevents


	/goto :loop
	
/return


Sub Event_testevent(string Line)
		/mac testmac2
/return

Once this is running issue "testline1" in guild, group or raid will fire the event to /mac testmac2

Testmac2

Sub Main
	/echo no macro to see here!
	
/return

This is very odd since from in-game i can issue a macro command manually if another macro is running and it ends the current macro and starts the one issued. Everybody that is impacted does use isboxer and mmo compile.

 

[sc0ttr0]

I cleaned my mq log and tried again:

very strange. It worked on the first attempt and killed the EQ session on the 2nd attempt.

[2018/12/02 10:37:56] [MQ2] test macro is running
[2018/12/02 10:38:24] The current macro has ended. <--testmac1 ended
[2018/12/02 10:38:24] The current macro has ended. <--testmac2 ran and ended but it did not issue the /echo command in testmac2

2nd attempt:
[2018/12/02 10:38:39] [MQ2] test macro is running
[2018/12/02 10:38:50] The current macro has ended. <--testmac1 ended and session died at this point.

 

[Chatwiththisname]

I have several small macros that based on chat text launch a different macro.

Since the patch last week, this completely freezes the EQ session. Others in guild that use the mmo compile experience similar issues. People using the other compile do not. I've set up a couple simple macs to duplicate the issue.


Testmac1

#Chat gsay
#Chat guild
#Chat raid


#Event testevent "#*#testline1#*#"

Sub Main
/echo test macro is running
	:loop
		/doevents


	/goto :loop
	
/return


Sub Event_testevent(string Line)
		/mac testmac2
/return

Once this is running issue "testline1" in guild, group or raid will fire the event to /mac testmac2

Testmac2

Sub Main
	/echo no macro to see here!
	
/return

This is very odd since from in-game i can issue a macro command manually if another macro is running and it ends the current macro and starts the one issued. Everybody that is impacted does use isboxer and mmo compile.

add a delay after the /doevents
Been known to cause issues to have a mainloop with a doevents and no delay

 

[sc0ttr0]

This does keep it from crashing the EQ instance by adding a /delay 5 after the doevents so thanks for that.

I do question why it started happening after last week's update (the first one). I've been using it in this fashion for multiple years now.

I made the chat event handle only changing a bool variable to true and then added a line in the main loop to test the bool value and only run the testsub if it tests TRUE. This made it all work perfectly without having to add a delay and impact it's responsiveness.

I did the following to testmac1:

#Chat tell
#Chat gsay
#Chat guild
#Chat raid


#Event testevent "#*#testline1#*#"

Sub Main
/declare testvar1 bool outer FALSE
/echo test macro is running
	:loop
		/doevents
		/if (${testvar1}) /call testsub1
	/goto :loop
	
/return


Sub Event_testevent(string Line)
	/varset testvar1 TRUE	
/return

Sub testsub1
	/mac testmac2
/return

 

[dewey2461]

Another thing you want to do is put a junk variable you don't want to use as the first variable in the main. I don't know why but with the distro I use you will get an undeclared variable otherwise.

foo.mac

Sub Main 
   /declare JunkVar int local
   /declare var1 int local 1
   /echo var1 ${var1}
/return

bar.mac

Sub Main
    /mac foo.mac
/return

 

[KingArthur]

I can confirm this bug since last patch..

Neither declare a dummy var at the first line of the macro nor add some delay will solve it.

It happends when you call a macro from another macro, it will randomly freeze the client.

I've been use this method over years too and recently the bug made me change a lot of my hotkey.

 

[sc0ttr0]

After more testing, I am seeing the same. Though I seemed to get the test macros working, it still randomly crashes Eq instances even with these changes when using it my real macros. I created hotkeys that Run the next macro and just a keypress as a workaround.

 

[Chatwiththisname]

I have several small macros that based on chat text launch a different macro.

Since the patch last week, this completely freezes the EQ session. Others in guild that use the mmo compile experience similar issues. People using the other compile do not. I've set up a couple simple macs to duplicate the issue.


Testmac1

#Chat gsay
#Chat guild
#Chat raid


#Event testevent "#*#testline1#*#"

Sub Main
/echo test macro is running
	:loop
		/doevents


	/goto :loop
	
/return


Sub Event_testevent(string Line)
		/mac testmac2
/return

Once this is running issue "testline1" in guild, group or raid will fire the event to /mac testmac2

Testmac2

Sub Main
	/echo no macro to see here!
	
/return

This is very odd since from in-game i can issue a macro command manually if another macro is running and it ends the current macro and starts the one issued. Everybody that is impacted does use isboxer and mmo compile.

As dewey mentioned, you do need a junk line of code at the start of any macro that will be called from another macro.

Test1.mac

Sub Main
    /squelch /echo this is a junk line, don't delete me, you'll never see it.
    /echo Test1.mac is now going to call Test2.mac!
    /delay 5
    /mac Test2.mac
/return

Test2.mac

Sub Main
    /squelch /echo this is a junk line, don't delete me, you'll never see it.
    /echo Test2.mac is now going to call Test1.mac!
    /delay 5
    /mac Test1.mac
/return

As for the validity of the entirety of the code that you listed in your example I cannot attest for the entirety of it and it's functionality. I'm assuming that's not the actual code that you are using that you are having the issue with?


I tried to find an instance of #chat in the wiki and didn't spot one.
If you need support for a specific macro, listing the entirety of the code for the macro would be the best way to get support for it, otherwise it's just going to remain speculation. If it can't be shared in this forum due to VIP or it coming from another website then support for that should remain in the forum in question as the most likely source for support for the macro. So if possible, share the files in question. If not, post it in the forums of the website it belongs to and link to it so that those with access to that can look at it. I'm VIP at MQ2's forums, and have access on RGs up to level 3. If it's not one of those I won't be able to access the information.

 

[htw]

Pound Commands - MacroQuest Wiki

 

[Chatwiththisname]

Pound Commands - MacroQuest Wiki

with the link provided by HTW that shows me the following.

Valid channels are: auc, chat, guild, group, ooc, say, shout, and tell. (chat represents channels)

gsay (group?) and raid isn't one of those valid options (I check Changes.txt to see if the wiki just wasn't updated). Additionally, it appears there is no Event_Chat sub for those to fire, which could be the cause of your crash. I recommend using this link to verify the existing code provided for the purpose of this thread.

Decided to verify this more by checking the core code itself. For AddMacroLine (which is part of the macro engine)

else if (!_strnicmp(szLine, "#chat ", 6)) {
			szLine += 5;
			while (szLine[0] == ' ') szLine++;
			if (!_stricmp(szLine, "say"))   gEventChat = gEventChat | CHAT_SAY;
			if (!_stricmp(szLine, "tell"))  gEventChat = gEventChat | CHAT_TELL;
			if (!_stricmp(szLine, "ooc"))   gEventChat = gEventChat | CHAT_OOC;
			if (!_stricmp(szLine, "shout")) gEventChat = gEventChat | CHAT_SHOUT;
			if (!_stricmp(szLine, "auc"))   gEventChat = gEventChat | CHAT_AUC;
			if (!_stricmp(szLine, "guild")) gEventChat = gEventChat | CHAT_GUILD;
			if (!_stricmp(szLine, "group")) gEventChat = gEventChat | CHAT_GROUP;
			if (!_stricmp(szLine, "chat"))  gEventChat = gEventChat | CHAT_CHAT;
		}

Above are your valid options. Where the valid option is the information inside of "quotes" IE: "say", "tell" "ooc" etc.

Those all have a CHAT_xxxxx where those are defined as

#define CHAT_SAY                        1
#define CHAT_TELL                       2
#define CHAT_OOC                        4
#define CHAT_SHOUT                      8
#define CHAT_AUC                        16
#define CHAT_GUILD                      32
#define CHAT_GROUP                      64
#define CHAT_CHAT                       128
#define CHATEVENT(x)                    (gEventChat & x)

CHATEVENT(x) would use those defined numbers to decide if it should process the chatevent. So those being corrected likely would be the first step towards avoiding the crash. Based on the code gsay and raid are just being ignored and couldn't be causing the crash. But the other chat event "guild" is still attempting to fire, but the Sub_Chat event isn't being found.

if ((CHATEVENT(CHAT_GUILD)) && (pDest = strstr(szClean," tells the guild, '"))) { 
				strncpy_s(Arg1,szClean,(DWORD)(pDest-szClean));
				strcpy_s(Arg2, pDest +19);
				Arg2[strlen(Arg2)-1]=0; 
				AddEvent(EVENT_CHAT,"guild",Arg1,Arg2,NULL);

 

[sc0ttr0]

In the example /rs chat will trigger that event.

It looks like, through reading the #commands that htw linked, #events monitor all chat (including mq2window). That being the case, monitoring chat and handling it with an #event is kind of dumb and probably just creates overhead. The two look somewhat redundant really since you can check for chat type and get sender and such with vars in the event itself. It looks as though #chat is useful to analyze all chat in a specific channel and possibly trigger things based on it's content? I will have to read up on this more to figure out the benefits of #chat vs #event. This was certainly a good learn.

On to the issue:

It really doesn't matter the macro. Calling a macro from a macro now has issues that it didn't before last week's patch and the behavior has been reported by two users in this thread running different macros. It is also not a problem with the other compile using the exact same macros posted on this thread nor with the actual macros I use in game. My guild uses them a great deal and all the other compile users do not experience this behavior.

If somebody wants to look into it great. If not, I have already figured a work around I'm simply reporting some challenges I've experienced since the last patch. I'll just take this out of the way I do things and it is a zero priority for me and should be for you guys with issue's lists here.

As always, thanks for the learns from the feedback.