Page 1 of 1

Macro features - Trial balloon

Posted: Sat May 26, 2018 5:17 am
by Meeply
I don't see a better spot to post this in so here goes.

I've been looking at macros for a bit now but I am pretty new here. This is not yet a feature request and I might wanna work on it myself if it doesn't exist and it sounds like a good idea to most folks. It seems there are issues with long running macros, macros that use plugins running async to the macro etc. My question/idea is:

Is there some kind of event, interrupt, or some feature that tells macros when they are being paused or ended? If not, how would you do the necessary cleanup in these cases? Would there be like an Event_MacroPause and Event_MacroEnd type feature that already exists? Is so I haven't found it in a lot of reading time. Common usages might be if using a plugin like mq2melee or mq2twist or others where your macro started something in there. Pausing or even ending the macros will not stop it. The biggest issue I see with making them pure events is that events seem to work like very old Windows code that did what was called "voluntary multi tasking" (Windows 2.x 3.x era) by letting other programs run between your larger chunks of code. In mq2 it seems calls do DoEvents calls are necessary in the main loops and even in larger subroutines. (Do I have this part right?)

So a built in set of events are dependent on being called at the right time and I'm concerned this might not work properly. A concept like an interrupt or exception could be introduced but would appear to be much more of a task to code but could take place anywhere. I know there are plugin calls that keep happily chugging away after the macro stops running for whatever reason. Could there be memory leaks etc. as well or other things that a long running macro might run into?

I'm not asking anyone to code this. I am asking the devs and people that know the bowels of this code whether this could be possible of not and if macro writers have been looking for features like this instead of using clunky workaround.

Thanks for the consideration.
Meeply

Edit: This would probably make more sense to belong in the Macroquest2::Development::Features Discussion forum but I don't have the ability to move it.

Re: Macro features - Trial balloon

Posted: Sat May 26, 2018 7:17 am
by dewey2461
I don't understand the "trial balloon" part of your title? Please explain ?


Each time EQ goes to draws a frame, MQ intercepts the call and starts executing its own stuff. When this occurs MQ calls each plugins "OnPulse" and the various plugins handlers OnIncomingChat, OnAddSpawn, OnRemoveSpawn, etc. Then the core MQ starts to run the current "macro", and will execute up to #TURBO lines of code before passing execution back to EQ.

Specific questions:

Is there some kind of event, interrupt, or some feature that tells macros when they are being paused or ended? - I don't think so because when they are paused/ended they stop executing.

Questions about DoEvents - Yes you need to call it to tell the macro to process events. You should have it in your main loop. Events should be short and set flags that your main loop uses to perform the actual logic.

Re: Macro features - Trial balloon

Posted: Sat May 26, 2018 9:44 am
by Meeply
The trial balloon was just an expression to see if it was worth while thinking about or if I was way off base. Clearly I still have a lot to learn about how the software works.

You explanations help a great deal. Thank you.

The OnPulse type functionality is what I am wondering about for the macro itself. In addition to calling the plugins OnPulse, could there be a overarching OnMacroPause and OnMacroEnd sent to the macros before they finish, giving it a chance to do some cleanup? The core seems to be handling the macros if I understand correctly, so could call the macros before they pause or end when /mqpause or /endmacro is entered. It clearly might be too much effort for the effect.

That was the basic concept. Just tossing around some ideas in my head.

Re: Macro features - Trial balloon

Posted: Sat May 26, 2018 4:14 pm
by dewey2461
Can you give an example issue / sequence you are worried about?

Since you are the one issuing the commands you could make your own pause / end commands and have the macro catch these and pause / end gracefully.

Example:

Code: Select all

#event MyEnd "#*#MyEnd#*#"

Sub Event_MyEnd
|-- User has requested the macro end gracefully
/varset DoEnd 1
/return

Sub Main
/declare DoEnd global int 0
:MainLoop
| -- Do something
/doevents
/if (${DoEnd}) {
  |-- Do my ending stuff
   /end
}
/sleep 1
/goto :MainLoop
/return

Notice how the main loop calls /doevents which tells the macro to go ahead and execute any pending chat events. The main also has a sleep 1 so that the main loop doesn't running multiple times per EQ frame.

Now when you want to end this macro you could /echo MyEnd --> which would the macro event would catch and set the variable DoEnd to 1 , which the main then uses to safely exit.

You could use binds and aliases to make that into a slash command like /myend

Re: Macro features - Trial balloon

Posted: Sun May 27, 2018 11:15 am
by EqMule
All macros can add the :OnExit label and do whatever’s cleanup they need there. It’s called after /endmacro

See documentation here: https://www.macroquest2.com/phpBB3/view ... it#p114817

Re: Macro features - Trial balloon

Posted: Sun May 27, 2018 12:39 pm
by dewey2461
There you go . Get to learn something new.

Re: Macro features - Trial balloon

Posted: Tue May 29, 2018 12:20 pm
by Meeply
The :OnExit is perfect! Thank you.
Is there an OnPause?

FYI - Not authorized to read the forum that contains the manual.

Re: Macro features - Trial balloon

Posted: Tue May 29, 2018 2:26 pm
by EqMule
There is no OnPause.