• You've discovered RedGuides, an EverQuest multi-boxing and scripting community 🧙‍♀️⚙️. We want you to play several EQ characters at once, come join us and say hello! 👋

  • A TLP without truebox has thawed (Very Vanilla ready)
    Frostreaver
Very Vanilla MQ (Live Servers)

Vanilla - Very Vanilla MQ (Live Servers) (3 Viewers) 3.1.52471.11

No permission to download
Any insight on the change of heart? I guess you kinda spoke on that in last reply; was it the fact that the developers came to the conclusion it DPG knows whats going on most likely and no reason to close source (pay for the review of code) if no reason to?
TLDR: Lots of Pain, Small if Any Gain.

We've been working on an agreement for two things, one is the initial review of the code, but the other is a retainer agreement to try to reduce the cost of auditing the code in the future given that it has the potential to change. I think I mentioned before that we were willing to pay the initial cost up front, but anyone else would have to pay for it on a go-forward. Honestly, it's kind of a hassle though and it's also fairly expensive, but the main reason is just that we're not sure it's worth the effort to try to keep it closed. The people who were circumventing it before are going to circumvent it again. We've been doing everything we can to try to make sure it's on the up-and-up, which is why dannuic wrote almost all of that code from scratch. MQ is GPL and pulling code from it and putting it into another library carries with it the likelihood that you're violating GPL, which means that some of the protections HAVE to be left out of that library because they were previously in GPL'd code. It leaves us with splitting our code into what was GPL and what is new and since dannuic, brainiac, and I all believe in the open source license it's been an interesting headache to say the least. So when it came down to it, we were spending a LOT of time trying to satisfy this requirement and to what end? We've been worried about a cat and mouse game with DPG because it's a lot of work to do that, but we're also already in a cat and mouse game due to the recent situation. Then there's the ongoing trust issues that it brings with it since the code can't be audited in any short timeframe and we've already had one situation which is all the more reason to audit it frequently. While we've been trying to make that as inexpensive and painless as possible, the reality is that Redbot is likely the only one who would ever call in that token and I doubt he'd call it in anytime soon. So we're starting to run thin on benefits over time/cost/effort of having this closed component.
Are the lines of communication still open between DPG and Red/Dev Staff from the recent suspension crisis? Have you or they had anything to say about MQNext?
I don't have the face for PR, that's @Redbot, but I'm guessing the lines of communication are always open (albeit not often used). But I don't think they really care about what revisions the tool is in, just what it does and how it impacts them.
In Red's post he said that they repeatedly brought up reaction times being faster than humanly possible and giving a significant advantage over a human player. As I remember the post about the conversation, there was going to be an attempt made at staying on their good side... has that been a factor in MQNext's development at all either at its core or guidelines for those converting current macros/plugins to the Next standard?
I'm all for providing helpers and doing what we can to make it easy to accomplish the goals that Redbot has. But we're not here to police the community so we're not going to try to put a limit or governor on the tool itself. That's what sites like RG are for -- community guidelines on appropriate use and what the community will and won't support/tolerate. But the tool itself is just a tool, it's how you use it that really matters. And I do believe most if not all of the work to accomplish the goals of being less impactful is in the hands of script writers.
 
this is all very exciting news @Knightly thanks to everyone for their efforts on this. I can't wait to see this launched and to be a part of MQNext
 
More of a broad, site-specific question, but will RG still provide the pre-compiled MQ2 for users who don't necessarily want to be early adopters of MQNext?
 
More of a broad, site-specific question, but will RG still provide the pre-compiled MQ2 for users who don't necessarily want to be early adopters of MQNext?
"Early adopter of MQNext" is a misnomer. That's like saying "Early adopter of MQ2Twist" because woobs just put in a bug fix for MQ2Twist. While Next was a huge overhaul under the hood, it wasn't written from the ground up, it is based on the existing MQ codebase with many enhancements and bug fixes.

As far as the site specific question, more of a question for Redbot question than an MQ question. Creators are able to use a pre-compiled MQNext version right now and we've had people using it since last year (though Creators were only added in December).
 
This is fantastic news. Always hated the macro language - not sure why - I've been a developer for over 30 years now and I've programmed in a vast number of languages, but just hated mq's macros lol.

My hat is off to you and all the developers who are making this a reality. Thank you.
 
This is fantastic news. Always hated the macro language - not sure why - I've been a developer for over 30 years now and I've programmed in a vast number of languages, but just hated mq's macros lol.

My hat is off to you and all the developers who are making this a reality. Thank you.
If you think programming in the macro language is bad, try maintaining it. Every little feature that all modern languages have has to be implemented by hand, and it's usually a mess of spaghetti everywhere. You get absolutely nothing for free. So while we won't be removing the macro language, it's absolutely in maintenance mode now. Lua is the first step, but I'm hoping some intrepid people step up and make more language plugins (there's already dotnet and a py plugin that could both probably be updated and converted, written by alynel and brainiac, respectively).

A huge part of the work I did for next was overhaul the typing system (which was a half-implemented variant) into something that's hopefully a lot more usable by more people (it wraps a variant now, I wanted to use any but that had technical limitations like crossing dll boundaries). I also hope that I or others can expand Lua in the future, and I have been actively adding features to it to get it ready. I just added a GUI to launch and run scripts as well as inspect their status. I'm pretty happy getting that in.
 
If you think programming in the macro language is bad, try maintaining it. Every little feature that all modern languages have has to be implemented by hand, and it's usually a mess of spaghetti everywhere. You get absolutely nothing for free. So while we won't be removing the macro language, it's absolutely in maintenance mode now. Lua is the first step, but I'm hoping some intrepid people step up and make more language plugins (there's already dotnet and a py plugin that could both probably be updated and converted, written by alynel and brainiac, respectively).

A huge part of the work I did for next was overhaul the typing system (which was a half-implemented variant) into something that's hopefully a lot more usable by more people (it wraps a variant now, I wanted to use any but that had technical limitations like crossing dll boundaries). I also hope that I or others can expand lua in the future, and I have been actively adding features to it to get it ready. I just added a GUI to launch and run scripts as well as inspect their status. I'm pretty happy getting that in.

I remember when the .net plugin came out years ago. I guess there's interest in Python as it's pretty hot right now with its growing use in data science work. Myself, thinking of what the very nature of what most macros' do lends itself to something that is built around eventing, such as node.js.
 
I mean, if you want to torture yourself with js, then write that plugin! I can probably provide some pointers. But I hate js, and think that node is an abomination that should never have become (get your damn front end code out of my back end). But I will coexist.
 
RedGuides will only support one version of MacroQuest.

That said, the next RG Launcher update will have two flavors: "developer preview" and "stable". One will be a work in progress, and the other a fully stable and supported version.
 
Last edited:
I'm hoping some intrepid people step up and make more language plugins (there's already dotnet and a py plugin that could both probably be updated and converted, written by alynel and brainiac, respectively).

I tried to look at reviving the dotnet plugin (C# is what I'm most comfortable with), but I'll admit I failed at getting very far. I hope you're correct that they are picked back up. Or maybe I'll take another stab at it after MQNext is available to me for building.
 
How does the frame limiter work? I can see that there's foreground frames, background frames, and simulated frames... but what do i set EQ ini to? What should the real EQ FPS be set at to maximize benefit? Ladon's screenshot example and he's doing 30 foreground, 30 simulated, and a fraction of a frame in background. What are the real EQ FPS settings though? Does that matter?

In the tinkering I've done, it seems to be incredible. Easily reducing resource load way more than eqwire does. I might even be able to run two groups on this old machine using this. I would bet that it gets even better once I learn how to set it properly.
 
I'd just set them to unlimited in game and control it through frame limiter. Simulation FPS is the rate the game loop will function, and the FG/BG render rates are the rate the graphics will render. The advantage of the framelimiter is that those are now independently controlled.
 
What are people doing to get around with Next currently? I didn't realize how much I use easyfind until i didn't have it.
 
I'd just set them to unlimited in game and control it through frame limiter.

Note that if you do this and /unload your computer may catch fire. I had to pull my laptop battery. My Mains group has 60/60 set in game as a hard limit now.

What are people doing to get around with Next currently? I didn't realize how much I use easyfind until i didn't have it.

Alt (or Ctrl??) map clicks to nav to that XY location, broadcasting doortargets, etc. It's been ~9 months and I don't miss easyfind.
 
I tried that, maybe it was operator error (likely). I'll give it another go and see if i can make it work.

Thanks!
 
I can left click map to navigate using mq2 but it doesn't work in next. I made sure mq2map was loaded, mq2nav, made sure i had mesh and that was loaded... everything looks great but it doesn't work for me.

I guess I'm running to places the old fashioned way for now.
 
Success! That added a line to my ini and it worked thereafter. I thought that was built in though?

Ladon saved the day! I was not using Next as much because that didn't work for me and it was a pain in the ass to move my group. Thanks!
 
I think it's built in but my Map ini was brought over from Live.
@Knightly can you confirm bae
 
RedGuides will only support one version of MacroQuest.

That said, the next RG Launcher update will have two flavors: "developer preview" and "stable". One will be a work in progress, and the other a fully stable and supported version.

Red, you guys will still build versions for TEST And LIVE though? As you know theres a fair amount of us that play a lot on test as well.. it would be a shame to lose our mq build for that!
 
Do we have any firm plans for mq2easyfind integration/replacement yet? Not that I'm desperate or anything ....
 
I dunno why it would be different in Next, I push RG's default MQ2Map.ini with the RG build. Though, I don't do that with the other builds, so if you're using a different build than the creator's one you might have different Map settings. Got me~

Next is setup to branch for Test/Live/Emu but we haven't done work on it. Test would be fairly easy to do though.

EasyFind is closed source so "integration" would have to be eqmule. Though I think he talked about letting Redbot open it, I don't think anything came of it. Someone will likely replace it though, it seems like a feature that would go well in Nav.
 
What steps need to be taken to migrate a current VV installation to this preview build?
 
This is a rough outline and might be missing steps, I haven't run Live VV in a while.
1.) Unzip the above zip file to a new location
2.) Copy your .ini files from the root VV folder to the "config" folder in the new distribution
3.) Copy your macros folder from VV to the new distribution
4.) Copy your meshes from VV\MQ2Nav to new distribution resources\MQ2Nav

If you want to keep your macros pointing at the current VV location (for auto updates and such) you can skip step 3 and instead edit the MacroQuest.ini in the new distribution to point to the old location.
INI:
[MacroQuest]
MacroPath=C:\Location\Of\VeryVanilla\macros

I think I did match the macros that are normally shipped with VV though, so it should mostly match up already.
 
What are people doing to get around with Next currently? I didn't realize how much I use easyfind until i didn't have it.

This is what I use in my MQ2Map.ini It adds some versatility but requires MQ2DanNet. Could swap around the commands to use EQBC if that is what you prefer. Just have it pasted at the bottom of the MQ2Map.ini and works perfect.

INI:
[Left Click]
#Shift + LClick = Melee
KeyCombo1=/dgexe melee /nav locyx %y %x |log=off
#Ctrl + LClick = All in zone
KeyCombo2=/dgzaexe /nav locyx %y %x |log=off
#Ctrl+Shift + LClick = Casters
KeyCombo3=/dgexe caster /nav locyx %y %x |log=off
#LAlt + LClick = Self
KeyCombo4=/nav locyx %y %x |log=off
#RAlt + LClick = Priest
KeyCombo8=/dgexe priest /nav locyx %y %x |log=off
 
This is what I use in my MQ2Map.ini It adds some versatility but requires MQ2DanNet. Could swap around the commands to use EQBC if that is what you prefer. Just have it pasted at the bottom of the MQ2Map.ini and works perfect.

INI:
[Left Click]
#Shift + LClick = Melee
KeyCombo1=/dgexe melee /nav locyx %y %x |log=off
#Ctrl + LClick = All in zone
KeyCombo2=/dgzaexe /nav locyx %y %x |log=off
#Ctrl+Shift + LClick = Casters
KeyCombo3=/dgexe caster /nav locyx %y %x |log=off
#LAlt + LClick = Self
KeyCombo4=/nav locyx %y %x |log=off
#RAlt + LClick = Priest
KeyCombo8=/dgexe priest /nav locyx %y %x |log=off
This is great. The default in the shipped ini is only the LAlt + LClick, love to see all the other stuff
 
**BUG**
Can't type in the moveable console. At all. I hit ctrl+` and it shows up / disappears, however can't use it to type. Potentially MQ2EQWire conflict
 
**BUG**
Can't type in the moveable console. At all. I hit ctrl+` and it shows up / disappears, however can't use it to type. Potentially MQ2EQWire conflict

console has input issues when moved out of the window, its a known issue. Also, MQ2EQWire isn't supported in mqnext, so did you mean something else instead?
 
console has input issues when moved out of the window, its a known issue. Also, MQ2EQWire isn't supported in mqnext, so did you mean something else instead?
Thanks Brain got with you on discord too. Just so others who may be asking, it was just my assumption it was EQWire. You are right, its not there.

The issues are out of screen, and as you suggested I simply moved it back in screen and all is well!
 
This is a rough outline and might be missing steps, I haven't run Live VV in a while.
1.) Unzip the above zip file to a new location
2.) Copy your .ini files from the root VV folder to the "config" folder in the new distribution
3.) Copy your macros folder from VV to the new distribution
4.) Copy your meshes from VV\MQ2Nav to new distribution resources\MQ2Nav

If you want to keep your macros pointing at the current VV location (for auto updates and such) you can skip step 3 and instead edit the MacroQuest.ini in the new distribution to point to the old location.
INI:
[MacroQuest]
MacroPath=C:\Location\Of\VeryVanilla\macros

I think I did match the macros that are normally shipped with VV though, so it should mostly match up already.
Cheers for this step by step, very useful

Am I right in thinking that paid plugins aren't compatible yet?
 
You'd have to talk to the owners, the paid plugins are all closed source and I only converted open source plugins.
 
Can a list start to be compiled of the closed source plugins that are ported so we don't have guessing games?
 
Did you mean "aren't" ported? brainiac's joke is that we don't have any closed source plugins in the build (because they're closed source so the author has to do it). So the list is:
 
I think the user was meaning a list of known closed source plugins that have been ported by their publisher to work with next, not necessarily included in the build.

I recognise the answer is probably still :
 
Yeah, I don't think that they keep a list of closed-source plugins. It's up to the developer of that specific addon to update it. Since they're closed source the Next devs have no idea what's done and what isn't.
 
I think the user was meaning a list of known closed source plugins that have been ported by their publisher to work with next, not necessarily included in the build.

Yes this is what I meant. If there are closed source plugins that are ready, it would be nice to know which ones so we can test them out as well. If a list can't be compiled it's ok, just figured I would ask.
 
Vanilla - Very Vanilla MQ (Live Servers)

Users who are viewing this thread

Back
Top
Cart