Macro features - Trial balloon
Posted: Sat May 26, 2018 5:17 am
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.
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.