• 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 --->

Plugin - Macros vs Plugins (1 Viewer)

Are we able to write our own plugins now? As per this thread: https://www.redguides.com/community/threads/writing-a-bot-plugin.43301/

"Writing plugins is basically closed source atm. Even if i provide you with the source code you cant really do anything with it due to it using members that you wont have access to."
well, anyone can write and compile plugins for the test server - if you want them for live you would need someone like redbot or mule to compile it for you
 
well, anyone can write and compile plugins for the test server - if you want them for live you would need someone like redbot or mule to compile it for you
Oh I see.. I'll have to keep this in mind if I ever create something other people could use :o). I'll keep developing my macro stuff for now. By the way I have been meaning to ask that what exactly is the difference between a macro and a plugin? I would think that they have access to the same info/TLOs?
 
Oh I see.. I'll have to keep this in mind if I ever create something other people could use :o). I'll keep developing my macro stuff for now. By the way I have been meaning to ask that what exactly is the difference between a macro and a plugin? I would think that they have access to the same info/TLOs?
the "backend" information comes from the same place, but the way you usually call it is very very very different

Recently trying to learn some plugin/C++ i can tell you that some of the programming principles are similar (understanding flow control etc), but they are very very very different.


Despite what some folks think, it is not a mere matter of taking a macro, with macro code, and then boom, magically turning it into c++

>>>GitLab <<< this is the VeryVanilla GitLab, you can see most of the stuff there. MQ2Feedme.cpp This is a link to mq2feedme.cpp - I recently added an addition onzone check to ensure we don't have the IAmCamping bool check still set to true (it would happen if we camped to character and then re-entered the game without fully exiting (the plugin wouldn't reinitialize and had no information on how/when to reset IAmCamping unless you manually camped and interrupted it (because there is an OnIncomingChat "event")
 
Despite what some folks think, it is not a mere matter of taking a macro, with macro code, and then boom, magically turning it into c++
Absolutely. I am very aware that writing a plugin would require a lot more investment, time and effort. I have eye balled the VV gitlab code before and I am not quite yet ready to start experimenting with any of it.

Main concern was that if there is some information I am not able to access with just macro code.
 
Absolutely. I am very aware that writing a plugin would require a lot more investment, time and effort. I have eye balled the VV gitlab code before and I am not quite yet ready to start experimenting with any of it.

Main concern was that if there is some information I am not able to access with just macro code.
the majority of information you would not be finding with macro code :(
 
That's not really true. Most of MQ2 is written around the macro engine, so the majority of what you would need access to is exposed in the macro engine.

That said, most of this thread isn't related to MQ2Py~
 
That's not really true. Most of MQ2 is written around the macro engine, so the majority of what you would need access to is exposed in the macro engine.

That said, most of this thread isn't related to MQ2Py~
Is exposed yes, but it is not macro code.
Ive spoken to many folks who think that plugins are literally macro code just inside a .dll

you're one of the most patient and knowledgeable folks around here, I was hoping you could articulate the differences for the me's and addict's of RG
 
Last edited:
I was mainly responding to "the majority of information you would not be finding with macro code." Since MQ2 is mostly designed around the macro code, the macro engine is really the best place to start.

But you are definitely correct that plugins aren't just macros in a dll.
 
I was mainly responding to "the majority of information you would not be finding with macro code." Since MQ2 is mostly designed around the macro code, the macro engine is really the best place to start.

But you are definitely correct that plugins aren't just macros in a dll.
yeah, I imagine what I'm trying to say and what I'm actually saying might not be congruent - heh.
 
The original intent of plugins was to extend the functionality of MQ2. Whereas macros were designed for automation.

We overlap in that area, but the reason for that design is that MQ2 doesn't deal well with concurrency in automation. Concurrency just being "doing two things at the same time." Whenever there is overlap in concurrency, there is usually conflict because the system wasn't designed to handle it.

In that aspect, it's not really that different from the idea of "running a macro while actively playing your character." It's not that you can't do it, but if you're trying to cast your rotation and your macro is trying to cast a different rotation, you're going to run into issues. Once you know about those issues, it gets easier.

This is the same with automation in plugins. MQ2Nav is a great example of a plugin that's "on the line" as far as automation goes. It's something that couldn't be done in a macro, but if you've ever used Nav on a fresh setup and tried to stop yourself in the middle of a route you'll see the conflict I'm talking about (your character fighting you to stay on route). Nav deals with this by adding TLOs to let you check what is going on.

Other plugins are just macro logic rolled up into different code. This is because the idea of "inc" files never really hit it's peak. It's not that you can't do something in a macro, it's more that you want to do one small thing and having to edit in an inc file to someone else's macro every time they update gets tedious. But for "shared logic" that was really meant to be what an inc file is for -- a file that contains just the logic itself and does one specific thing really well.

From a distribution standpoint, as a community we've tended toward the "one file" approach. Probably out of lack of organized distribution and tracking methods to start. You can see this in the way that most plugin cpp files are written, in the way that distributed macros are written, etc. That's likely another reason there is overlap in those areas.

But, getting back to the original question. Start with a macro. It's a good way to get your feet wet and decide how you want to do something. Macros are extremely forgiving and since they don't require compilation and most commands can be /echo'd to see what's going on, they're mostly easy to work with. There are also a lot of great resources in that area to provide guidance and help.

When you hit a solid wall because you're missing something that you could really use in a macro, that's when to start looking at plugins.
 
Plugin - Macros vs Plugins

Users who are viewing this thread

Back
Top