-
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! 👋
- Thread starter Knightly
- Start date
This project doesn't need a cult of personality. This thread is for people to ask questions about Next, not for you to bloviate about your importance or get extra hits in on Mule.
brainiac answered the first part of this, but expanding on his answer -- Lua identifies scripts using a process ID (PID) and you can stop or pause using that PID. You can also stop all, as needed.
While we can see the crash, it doesn't tell us anything about what steps you were doing to reproduce the crash, so it's absolutely helpful to register an issue on git for a reproduceable issue (which I saw you did). In the case of overlay crashes it's usually conflicting with another overlay, though we've rooted a lot of those out. (Example common overlays are: Steam Overlay, Nvidia, Windows 10, etc).
We use imgui as our interface and as I mentioned above one of the really cool things is that Lua script writers can use it too without having to build a plugin of their own. But right now brainiac has built a window inspector and a spell inspector and integrated it into the EQ menu. But as for what the interface does, that's up to the authors to take advantage of, we're just building a toolset.
Poor Lemons, just getting his macro name changed randomly now. I don't use either of those macros so I'm not a good one to speak about it. @toadwart has been testing KissAssist and @Lemons has been testing MuleAssist. They can likely speak better.
We've added a few new TLOs, though most of the ones I added were just getting paths. Some of the ones we added got backported to Live already. And still others that have been asked for are in issues up on the issue page. As far as what end users will notice if they just load up a macro and go on about their business? Hopefully nothing, honestly.
Anything is possible, but there's a lot that you can do with Lua that you can't do with the macro language, so it's probably a good opportunity to write something new rather than just try to convert. Everything in the existing macro language (that works now) will work in Next, so there's not a huge driver to convert old things. And a straight convert would lose taking advantage of all the new stuff Lua offers.
We did go back and forth on what language to use, but the way dannuic wrote it, this is actually a precursor to allowing any language to be integrated. Though we still want to go back and move everything to C bindings that would REALLY open up languages and make integrating any language a lot easier. I'm a huge Python fan, but Lua is also used in eqemu (and as you mentioned lots of other places as well) so it offers some nice parity.PS. Personally I'd have loved Python support but Lua is a fine choice. 1-based indexing ugh
Are there any plans on porting MQ2EasyFind? It's crazy just how reliant I am on that functionality for QoL stuff. I remember in the old days recording AdvPath's to get between zones, but Easyfind is so much simpler (when it works), I use the Ctrl+F menu all the time even for manual play, and /travelto is super handy when I'm lazy.
Easyfind is closed source, so we won't be porting it directly, but we have talked about what a replacement would look like. In the meantime, alt+left click on the map is an okay workaround that gets you most of what easyfind did.
You can do that now with any of the .cfg files to launch whatever you'd like at different points (char select, login, zoning, specific classes/characters).
Tiger
Well-known member
- Joined
- Nov 11, 2017
- RedCents
- 910¢
I have no questions because quite honestly, most of this stuff goes way over my head. Just wanted to say thanks to everyone involved in this, I feel it's been a bit of a depressing time on the forum the past month or so with everything that's been going on. Nice to have something positive to keep an eye on. Cheers, Tiger.
Put a request up on the issues page. There's a lot more work we need to do on the console, but brainiac already worked on IPC to be able to communicate for something like that. Not saying we'd do it, but all the pieces are there.
To me it would be really cool if I could sort issues by how many people "Thumbs Up'd" the feature request, though that's probably a pipe dream Still, that's what the page is for.
This is awesome! Excited for the next step evolution of the program. This thread is actually the first I've even heard of it, so I'm somewhat behind the times. As @Tiger commented above, thank you to everyone who's put the time, energy, and brain power behind and into this project.
I know it's still in development, but is there a time frame out there for when this goes "live" for the minions?
I know it's still in development, but is there a time frame out there for when this goes "live" for the minions?
r1pt1de was working on getting it into the launcher. We have a few more things to do before we go for open beta, but timing wise I think the quote from Money Pit is appropriate: "two weeks."
Realistically speaking, there's nothing we can do to prevent that. MQ2IC just became a cat and mouse game between eqmule and the people who were cracking MQ2IC, as you can see from the history on the subject. I think what did more to stop it than IC was that RG wouldn't support a Truebox build, so if someone wanted a build for Truebox, they either had to build it themselves, crack MQ2IC, or pay someone to crack MQ2IC for them. That last bit ended up creating a black market, but the vast majority of RG users respected the no Truebox rule. We'll do what we can, and RG's build won't work on Truebox, but once you have something locally on your computer it's only a matter of time before you're able to bypass it.
Reference one of the above comments, I'd love a console with programmable commands outside the game and have some wish list items. Example, click a button labeled /travelto, type a zone name, and click the characters you have loaded and it runs everything for you. Having a presaved kiss assist macro on one character tab outside the game would be amazing. I'd love it to have the chat spam in the console instead of, or reducing, the spam on the ingame mq window.
I have yet to see mqnext. Just tossing my idea out there. I'll look up the issue page as described above if that would help my wish come true.
I have yet to see mqnext. Just tossing my idea out there. I'll look up the issue page as described above if that would help my wish come true.
brainiac integrated imgui (the same console Nav uses) and dannuic integrated Lua (a scripting engine) and together they can create windows that can be moved outside the EQ frame. They can be interactive, allowing input or changing of settings, and everything on your list can be done. It probably won't be done in core, but the great thing about MQ is giving people the ability to tinker and drive forward the things they like. The chat window thing outside the game already exists though, we call that the "console."
It's actually called "MacroQuest" and there are only two places related to the code base that reference Next -- the name of the repos (which will be changed when we release) and one of the TLOs to get the version that was added so macro writers could split their code for new features that don't exist in Live (and which will become Live at release). The exe you launch with is MacroQuest.exe and all of the titles are MacroQuest.
But, if we were to refer to it by MacroQuest when different versions of MacroQuest exist, that gets confusing. We couldn't call it "Test" or "Beta" because those are named for different EQ clients. The name "dev" was also already being used for what eqmule calls the version he has on his computer (he alternates between "fixed internally" and "fixed in dev") but we tried using Dev anyway and that was just as confusing.
We started the project over a year ago so the Next terminology was just a joke about it being vaporware. From there it became an easy and unique way to reference it and just stuck for convenience. At release though, it just goes back to MacroQuest or MQ.
Last edited:
ToeJamSamy
Seasoned veteran member
- Joined
- Nov 21, 2020
- RedCents
- 804¢
my brain doesnt always retrieve info as it should... am i forgetting where it is , or isn't there SOMEthing that uses perl? it is just Lua and c++ pretty much? been meaning to get back into writing shit and Next seems a good time to start rather than write for one then convert and get in habit of writing different way when it gets released, but i need to brush up on my knowledge as its been a few years. i used Lua, perl, and sql before, never c++ but i have tons of c++ references and thats not really applicable for what i'd do anyway. Should we mainly focus on Lua if we want to write anything for Next? as far as plugins or macro-esque toys? does perl even have any application or am i just senile? I'd be quite happy to be working in any standardized language rather than the proprietary one for macros now lol.
are there any particular types of macros (Lua that is, but regular too i suppose for smaller stuff) that would have to be rewritten, altogether, or dont really exist yet in any modern form? I can't access the files yet obviously, but i could work on small projects that would work in both (we have mq2lua now iirc, just never used it) Just wondering if therere any little blocks that are needed or wanted but that arent really worth the time right now for the main developers, that some of the rest of us could work on, creator or not
are there any particular types of macros (Lua that is, but regular too i suppose for smaller stuff) that would have to be rewritten, altogether, or dont really exist yet in any modern form? I can't access the files yet obviously, but i could work on small projects that would work in both (we have mq2lua now iirc, just never used it) Just wondering if therere any little blocks that are needed or wanted but that arent really worth the time right now for the main developers, that some of the rest of us could work on, creator or not
I'm not aware of any perl plugins, but maybe you are thinking of the python plugin that brainiac had? It's not up to date. There is also alynel's C# plugin.
Next supports C plugins, Lua, the macro language, write in whatever floats your boat at any given moment. Though, personally, I'll be relearning Lua.
I don't think anything necessarily needs to be rewritten, but I think it would be super cool to see some of the current popular plugins improved upon using Lua. (I'm looking at you, AutoLoot).
Since a lot of the talk here has been about Lua, I thought I'd drop the Lua doc I just wrote up:
gitlab.com
MQ2Lua · Wiki · macroquest / next / MQnext · GitLab
We moved to github, go to https://github.com/macroquest/macroquest instead.
gitlab.com
@Knightly Out of curiosity, what are your thoughts on when this will be released?
I know "When it is ready".
Also is it backwards compatible with the current plugins and macros?
Is this mostly large change for Macros, or are plugins affected much also?
I know "When it is ready"
.Also is it backwards compatible with the current plugins and macros?
Is this mostly large change for Macros, or are plugins affected much also?
It's mostly backwards compatible -- plugins will need to be recompiled and there are some things that need to be updated, but I've converted a lot of plugins myself (just did NetBots, AutoSize, and Rewards this weekend) and it's a fairly quick process. Macros should work. We have testers from KissAssist, RGMercs, Entropy, and most recently modbot.
Plugins are impacted more than macros, but only because they have to be compiled.
.
Autumn
Well-known member
- Joined
- Dec 1, 2019
- RedCents
- 69¢
HYPE HYPE HYPE HYPE
- Joined
- Dec 29, 2017
- RedCents
- 23,976¢
Good movie.
Earlier I had said that we would likely be getting an independent third party to review the closed source library. After much deliberation and although we're still in talks with the company that provides Black Duck, we've decided to roll forward without even our own closed source library. Given that we've gone back and forth on this a lot since we went down this path, that's obviously subject to change but right now we're likely to roll forward as fully open.
DPG already knows how we do everything we do. For the most part we use the windows detour library to detour functions in the game client. At best it would tell them the ones we know about and the ones we don't, but anything they would do to stop it is independent of the current how.
craggyisland
Unwise Decision Designator
- Joined
- Apr 7, 2020
- RedCents
- 569¢
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?
Btw I'm sure all of us appreciate the AMA and directness you have shown. I for one am waiting for those two weeks to finish. When you hear the code start singing this song its time to release ok?
Btw I'm sure all of us appreciate the AMA and directness you have shown. I for one am waiting for those two weeks to finish. When you hear the code start singing this song its time to release ok?
Last edited:
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? 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?
If so, I would totally understand any sort of hesitation/unwillingness to answer that question in light of previous agreements/dealings gone south or blown out of proportion (blink twice if they are listening). I was just curious if the two threads had any correlation in that regard. I 1000% do not wish to turn this thread into the dumpster fire that is the other thread! I just want to know if you guys are baking in the things discussed previously into MQNext... which may or may not explain the change of heart concerning the code review/certification.
If so, I would totally understand any sort of hesitation/unwillingness to answer that question in light of previous agreements/dealings gone south or blown out of proportion (blink twice if they are listening). I was just curious if the two threads had any correlation in that regard. I 1000% do not wish to turn this thread into the dumpster fire that is the other thread! I just want to know if you guys are baking in the things discussed previously into MQNext... which may or may not explain the change of heart concerning the code review/certification.