• You've discovered RedGuides 📕 an EverQuest multi-boxing community 🛡️🧙🗡️. We want you to play several EQ characters at once, come join us and say hello! 👋
  • IS THIS SITE UGLY? Change the look. To dismiss this notice, click the X --->

Question - Help with Modular design of macro (1 Viewer)

Joined
Feb 8, 2005
RedCents
8,490¢
Ok so I want to make a modular design in the automacros section but right now the only way to do this is doing an include for every class. As you can imagine adding that much code will drastically slow down the macro. Wanted to see if any other coders out there had any ideas.

Here is what I had envisioned
Rich (BB code):
#include autosubs.inc
#include auto_${Me.Class.ShortName}.inc

That said, you can't use variables or TLOs in the #include.

So that leaves me with some ugly options and wanted to see if anyone had any better ideas. Launching a macro with a macro is always dicey and I'd like to avoid it if possible.
 
Ok so I want to make a modular design in the automacros section but right now the only way to do this is doing an include for every class. As you can imagine adding that much code will drastically slow down the macro. Wanted to see if any other coders out there had any ideas.

Here is what I had envisioned
Rich (BB code):
#include autosubs.inc
#include auto_${Me.Class.ShortName}.inc

That said, you can't use variables or TLOs in the #include.

So that leaves me with some ugly options and wanted to see if anyone had any better ideas. Launching a macro with a macro is always dicey and I'd like to avoid it if possible.
Not sure what you mean by class specific material, but an all class plugin (think melee but for class abilities etc..) may be the smoothest way to go.

Sent from my XT1635-01 using Tapatalk
 
Not sure what you mean by class specific material, but an all class plugin (think melee but for class abilities etc..) may be the smoothest way to go.

Sent from my XT1635-01 using Tapatalk

The problem with that is I have to include every class it will bloat the macro to be just as big if not bigger than Kiss. This will make it slow... Hence why I wanted to just include a specific .inc when the macro is launched. This might be pie in the sky at this point, and I'll probably have to ask eqmule about it.
 
could you do something like:

Auto.mac
Rich (BB code):
#include autosubs.inc
#include Class.inc
/call classselect ${Me.Class.ShortName}

Class.inc
Rich (BB code):
#include auto_${class}.inc

if that makes sense?

but probably not.
 
I don't know anything about coding, but whats wrong with having 16 class include files, and forcing the user to just write in only 1 of #include Class lines and renaming a base macro file (for the below example I called it automacro.mac)


So it would be something like

automacro_cleric.mac (renamed from automacro.mac)

#include autosubs.inc
#include autocleric.inc


automacro_bard.mac (renamed from automacro.mac)


#include autosubs.inc
#include autobard.inc



So you are not calling up 16 include files that way right, since each macro file is only pulling up only 1 include. Force the user to rename the file. And if anyone writes a custom script for the class, they would be writing the include file, and you could just insert the new #include filename into the automacro.


Most users will probably end up having 8-10 macro files (doubt many users play all 16 classes) , but thats on them if they want to use your macro, its a little bloating of your macro folder though.
 
I don't know anything about coding, but whats wrong with having 16 class include files, and forcing the user to just write in only 1 of #include Class lines and renaming a base macro file (for the below example I called it automacro.mac)


So it would be something like

automacro_cleric.mac (renamed from automacro.mac)

#include autosubs.inc
#include autocleric.inc


automacro_bard.mac (renamed from automacro.mac)


#include autosubs.inc
#include autobard.inc



So you are not calling up 16 include files that way right, since each macro file is only pulling up only 1 include. Force the user to rename the file. And if anyone writes a custom script for the class, they would be writing the include file, and you could just insert the new #include filename into the automacro.


Most users will probably end up having 8-10 macro files (doubt many users play all 16 classes) , but thats on them if they want to use your macro, its a little bloating of your macro folder though.

This is actually not a bad compromise. Hell I think I can even doing /mac auto_${Me.Class.ShortName}.mac will actually query auto_CLR.mac. I'm going to try this out, I already have all the inc files written but never imagined running into the roadblock with #include not parsing anything.
 
Do it the other way around

Use .mac for class-specific
Use .ini for shared

automacro.mac = loader and initial ini setup
automacro_XXX.mac = class specific subs
automacro_all.inc = sub's that every class would use


Rich (BB code):
|
| ##########
| automacro.mac
| ##########
|
sub main
  /if (!${Ini}) /call makeINI
  /mac automacro_${Me.Class.ShortName}.mac
/end


sub makeINI
 /ini auto_${Me.Name}.ini
/end

Rich (BB code):
|
| ##########
| automacro_XXX.mac
| ##########
|
#include automacro.inc
 
I use to have issues when calling a macro from a macro. Then I discovered the :OnExit label you put it right after your Sub Main

Rich (BB code):
    Sub Main
     ...
    /return
    :OnExit
     /macro SomeMacro.mac

After using this method, all the quirky problems I use to have, went away. The MQ2 code searches for the :OnExit label when exiting a macro no matter what the reason. /endmac or even from an error causing the macro to crash, the :OnExit section is executed, if it exist..
 
This is actually not a bad compromise. Hell I think I can even doing /mac auto_${Me.Class.ShortName}.mac will actually query auto_CLR.mac. I'm going to try this out, I already have all the inc files written but never imagined running into the roadblock with #include not parsing anything.

I have all the classes for afdps.mac in afclasses.inc . Certain stuff is in the core of the macro but everything else is class specific. So it only parses stuff for your class.
View attachment afclasses.inc
View attachment AFDPS.mac
View attachment General.inc
 
Here is another little tidbit I use when calling macros from other macro that really helped me in controlling things.

For example lets say I have a macro, Lets call it Mastermacro and in master macro I want to control what macro I want to launch next. Now just to keep this simple, lets say the macro I am going to call is called Autocleric. Now one way to control communication or passing data between the 2 macros is using paramaters, but there is another way that is even better. Their called Global variables. Now Global Variables are maintained outside of macros so when a macro ends the global still persist.

What I have done before is in My called macro(AutoCleric) in the top of Sub Main I put a check to check if the global variables exist, so I know that it was called from another macro and not launched from a command line.

An example would be: In the Mastermacro I would declare a variable like /declare MacroToCall string global. Somewhere in the mastermacro I would determine what to set MacroToCall to. /varset MacroToCall AutoCleric.mac. Then in my Mastermacro I would have my :OnExit section setup like this.

Rich (BB code):
:OnExit
    /macro ${MacroToCall}

Now in the AutoCleric Macro I would have this code:

Rich (BB code):
    | Check to see if global variable exist.
    /if (${Defined[MacroToCall]}) {
        | Is the global variable set to the current macros name. 
        | Make sure you include the .mac when setting the variable from other macro
        /if (${MacroToCall.Equal[${Macro.Name}]}) {
            ...
            ...
        }
    }

Then in the :OnExit I would do basically the same thing

Rich (BB code):
    :OnExit
    | Check to see if global variable exist.
    /if (${Defined[MacroToCall]}) {
        /macro MasterMacro
    }

There is a lot more you can do with this, but this should help in getting started, IF you decide to do something of this nature.

And get to know these 2 TLO's They are your friend when trying to figure out if something failed or not when going from macro to macro:

https://www.redguides.com/wiki/DataType:macroquest

https://www.redguides.com/wiki/DataType:macro
 
Question - Help with Modular design of macro

Users who are viewing this thread

Back
Top