Idea - Discuss the possibility of an "interrupt system", making sure the most important functions are prioritized

[Redbot]

CWTN and Knightly brought this up in the other thread, and I think it deserves more discussion.

Having been writing plugins for a whlie now. I've seen the responsiveness of the pass through functions where waiting isn't an option. That is to say that if you can change things in the main routine to be "pass through" type functions where it either does something or moves on allowing a consistent loop during combat, with the option to reset to the top of the loop after every action, it would allow for healing to be place on the top of the priority list, followed by mezes, followed by everything else in some considered order. Using this method for my plugins allows it to instantly recognize low health, that the group has aggro, that things are in need of a mez or a buff etc. I can disucss this specific idea in more detail if you're interested in considering it. This would be a big change to the way the main loop currently functions and thus a lot of work to remove as much delaying or while loops as possible.

Inkie and I were just having a similar conversation to that loop statement that Chat made and it's a very good point. One of the things I mentioned was that neither plugins nor macros as written have an interrupt system, so making sure that you're not getting stuck in a loop or a sub is important to overall responsiveness of the macro. As Chat mentions, this is especially true in things like...aggro, heals, mez, etc. So, creating interrupts for these "trigger" actions or making your loop go fast enough that you are already back to the top if one of them happens is important.

 

[B_I_G__D_A_D_D_Y]

Let me throw fuel on this bonfire.

We find 2 plugins now providing additional user-defined actions (MQ2Events and MQ2React).

When using either of those plugins to "do something special" we invariably issue a /mqp on command as one of the first steps. In other words we want to take control away from KissAssist long enough to perform some special function. When complete we transfer control back to the macro. (That's the theory anyway!)

Wouldn't it be wonderful if those actions could be provided in an Include file so that either Events or Reacts would simply invoke a flag that would cause KissAssist to call a user-defined subroutine and we never have to stop or pause the main macro thread?

We already do this with NinjaAdvLoot.INC and I already make custom modifications to that file to gut it of all loot-related actions. I could easily insert more subroutines into the INC file if only there were some way to have KA branch on these user-defined flags.

I'm inserting this post here because I believe a feature like this would need to be implemented as an interrupt. Man can you think of the mischief us half-assed coders could get into with this!

 

[ctaylor22]

@B_I_G__D_A_D_D_Y KA 12 has the ability to use an .inc file for custom code. You have to enable it and you have to write your own routines. But we added a /mycmd bind so you could call your routines using it.

I am not sure about the plugins and how you would set them up.

 

[vsab]

When I wrote my macros (they were similar to RGMercs but this was 5+ years ago and I couldn't be bothered to fix them) I had a way to hook into the normal loop. It was easier for me as I ran a different script per class (again like RGMercs) and so the bard and chanter interrupted everything in order to mez, the cleric interrupted all to heal etc. I did generalise this by having a variable call HighPriorityFunction (or something similarly snappy). If it was defined, it was called at key points. It may have done nothing or it may have executed the mez/heal etc. If it wasn't defined, it only cost the macro a single boolean check.

If we're talking about another interrupt system built into MQ2 then we might cause all sorts of pain, as there is a certain amount of predictability you require when writing a macro, and interrupting the macro flow control could be very hard to debug...

 

[ctaylor22]

Macros are extremely Linear compared to Plugins. Without adding extra code everywhere checking to exit/abort a routine then in the returning routine checking some flags status letting the macro know to skip everything and start at the top of the current loop. That would be a lot of extra code. It could be done. If there was a way to tell MQ2 to redirect things internally from a macro, I could see this not being as difficult. Like a way of leaving a routine telling MQ2 to not only return from a routine, but reset to the top of the current loop, it is returning to. So from within a /While () loop it would just reset you to the top of the loop, not requiring any additional commands in the macro.

I am just thinking out loud here. Kiss 12 already has almost 15000 lines of code, I don't want to have to add more if I could help it.

 

[Knightly]

Answering that question, this is how binds, events, and subs all work (albeit they all work differently). The macro engine is just "where am I now and what should be next"?

Also, plugins are just as linear as macros (unless you spawn a thread), they just happen at different times.

 

[ctaylor22]

You can only run 1 Macro at a time, how many Plugins can be loaded at a time? You can write a lot more flexibility into a plugin, than you can a macro. Just compare the MQ2 macro language to the C++ language. Yes most everything is linear, but what the C++ language gives you in terms of flexibility is far far more flexible then what you have to work with when dealing with MQ2 macro code.

 

[Knightly]

Redbot was talking about new functionality, so if you're adding the functionality to interrupt or inject a sub, that idea of no concurrency isn't in play.

Regardless, you cannot run two plugins doing the same thing at the same time. That's why CWTN has to unload MQ2Melee for all of his plugins. The difference between letting you do something and being effective is important here.

All macro functionality is implemented in C++. So nearly the same amount of effort goes into making a function available to a macro as it does making it available to a plugin. In many cases, especially with TLOs, it's actually harder on the writer to get the information into a plug-in than it is to get it from a macro.

While I don't disagree that C++ is more flexible, that doesn't change anything about what I said earlier.

 

[B_I_G__D_A_D_D_Y]

Some coding discussions are largely the same no matter the language or the era. I just like the idea of programmers always thinking about how to bail out of subroutines when things go wrong. Makes for stout apps.