1. Right now those with the creator title can try it out, will you ever decide to invite regular members to the closed beta for UAT or QA?
We had actually invited some non-creators as testers prior to having it up for Creators. Creators is just who has access to that on RG.
@r1pt1de is working on getting it into the launcher already, I believe. When that's ready we'll need to change the crash reporting to off, and then we're ready for open beta. Right now it's a little humbug because you have to go manually download every update.
Conversely, i wonder how i can get the creator title without being able to program...
You can make Creator for really good guides or maintaining and posting ini files as well.
2. Are there any features of MQ2Next that you guys are especially proud of, something exciting for us to hype up and look forward to perhaps?
It's funny, most of the features I'm proud of are ones I didn't have anything to do with.
Lua, of course, which dannuic did the work for. But I still giggle when I move the ImGui console outside of the EQ window (even though it's a little buggy). That's something brainiac wrote probably more than a year ago and it's just super cool to me. The window inspector is also pretty awesome if you're doing anything with the UI, it's actually how we realized that there were two of the Yes/No dialog boxes and that windows weren't unique which is what allowed us to fix that for MQ2Rez and all that last year (in Next). I think being able to generate a UI from a
Lua script on the fly is pretty amazing and opens up a world to script writers that was previously only there for plugin authors. The built in frame limiter is super cool and works amazingly well and having all of the options in a menu is very cool as well. Those are the ones that come to mind.
3. In some random discussions about MQNext here and there, it was stated that MQNext offers improved performance over MQ2, could you speak to that? What improves?
Some of the containers have changed and we've modified a lot of code. Many of the speed improvements are accidental and just come from cleanup on the code. There weren't many deliberate attempts to improve speed, but we did set out a few times to improve load times -- I mention above that the spell load times improved by a factor of 4 just by changing how it's done.
Someone said that eqwire isn't necessary with MQNext as it's performance improvements are enough?
We built in a frame limiter that replaces much of the functionality of eqwire, so it's not so much that performance improvements are enough as a different method of frame limiting was put in place as part of the base package. @william12 can probably speak to the performance benefits here.
In MQ2, macros and plugins have a little bit of a performance gap. Plugins seem to always be more responsive and snappier than macros, will the performance improvements of MQNext close this gap a bit? Am I way off track with performance improvements here?
Delayed code is delayed code, even in Live there shouldn't be a noticeable difference in macros and plugins that are written the same way. I think the reason this comes up is because in a macro you can add as many delays as you want while you "wait" for stuff. In a plugin, if you "sleep" you're going to sleep the whole thread (including the game, unless you're multithreading). This forces people to make different design decisions in plugins, switching from "delay" to "check if I'm ready to do this" which is more of a state management philosophy. So I think responsiveness is probably in having had to remove all the "wait for this" stuff which you can do in a macro just as well as a plugin. The only other bit is probably slash commands since there are only certain times that bind commands execute in a macro, while in a plugin those slash commands are always called -- this
might give the appearance of sluggishness in a macro (to the user) but it's really just a design issue on the part of the author. (ie, for binds to be more responsive, call them more frequently).
I think the primary reason most people switch to plugins is for simultaneous action. Ladon lists a bunch of plugins above that could be done in
Lua because
Lua can run concurrently. That's not really an option in Live -- if you want simultaneous action while running a macro it HAS to be in a plugin. But most of the plugin language is designed around adding capability for macro writers and less around adding automation, and that's where something like
Lua really shines (it's much easier to evaluate a TLO in a script than it is in a plugin). Though we have it on our radar to remove that plugin issue as well, though not for release.
4. The IC replacement, you said that you guys are discussing a 3rd party code certification likely to prevent another instance where what it does is in question and to inspire confidence and trust in the application. You said you guys would pay initially but after that we'd have to pay for updated version.... updated version of what? The certification or the plugin itself? What did you mean?
When you certify code it's a point-in-time snapshot of the code. One of the reasons that DPG can't say "This third party program is okay" is because as soon as they say that, we could change it. That goes for any third party program, so they call out the actions that are against their Terms of Service (like automation and basically everything MacroQuest does) rather than specifically allowing certain things. If they said "InnerSpace is okay" but tomorrow InnerSpace started adding automation in again, then they'd have to remove that from their Terms of Service again and it's a constant battle to say what's okay and what's not okay. I bring this up because code changes over time. Even just "oh, we found a bug, so we had to update this" is a code change. So it's unlikely we're going to pay for a full code review every time that happens, but it also means that as soon as we make a small code change, the old certification of the previous code is out of date. You can reverse engineer the code to see what changed and that we didn't add anything nefarious, but we wanted to allow the option that at some point in the future someone might say "Hey, enough has changed, can we get an updated code review?" and, as long as it's not coming out of my pocket, the answer will always be yes. (Note that I did say from a respectable independent agency and not like "My cousin John reviews code for a living"). Although, if your cousin John does review code for a living and works for a known company, I'm still looking for a good respected agency that will do this on the small scale we're working without a full engagement.
Did you mean the IC replacement will be a paid plugin? Did you mean that the community would have to pay to have it recertified as it was updated when necessary? (isn't independent code review and certification in the thousands of dollars? perhaps my perspective on the cost is skewed because I work in IT, on the infrastructure side, and only hear conversations in passing about this topic.)
No, the replacement won't be a paid plugin, our group is very focused on getting MQ back to Open Source and one of the things that was paramount to plazmic was that this code not be sold. It's why the license is GPL v2, which none of us would actually have chosen for a license due to its restrictive (ly open) nature. And yes, independent code review is quite expensive. Most companies want a full engagement over a long period of time, but I think it's important enough if we're going to keep a closed source plugin to 1.) Prove that we're not violating any license since this was written from the ground up and doesn't depend on any GPL code and 2.) after what happened with IC, regain the trust of the community. So we'll pay for it ourselves the first time around, but our altruism in that area only goes so far -- when the code is updated if someone wants it they can do it every time it changes to their heart's content, but we're just not footing the bill for that. So it's a compromise, but with the caveat that anyone wanting to can verify the integrity. There's also the other method as well -- Reverse Engineer it -- but then you're having to trust the word of other people which really isn't that different from trusting brainiac, dannuic, Redbot, and me (and alynel, but he's not that active right now). So, my preference is to have that be done by an independent party.
Will the IC replacement anger DPG in any way? Maybe they like the self reporting feature of the current IC? I'm sure you guys have already anticipated this and improved the protections.
If anything, they'll probably be glad that their Woebot mailbox stops getting spammed~ But in seriousness, if it does anger them...it is what it is. It is my opinion that IC is doing more harm than good at this point, and eqmule has intimated that he's specifically not blocking some of the eqgame calls that look for MacroQuest as well as the reporting code. If people weren't getting suspended and banned, you could argue that IC is doing its job. But people are getting suspended and banned so its not a good enough protection mechanism. Our concern is with protecting the MQ community and not with appeasing DPG. That said, obviously we don't want to piss them off, but we're going to do everything we can to hide MQ so that our users are safe, this community has to come first. If you get suspended or banned, it's going to be because either you were doing something that deserves to get you suspended or banned or because we completely missed a brand new detection mechanism and have to update the code to account for it. It's not going to be because we intentionally left something out or added a reporting mechanism in. We don't think that will anger DPG, but if it does, we'll deal with it the same way we did the 15 years prior to self reporting.
Smile and wave, boys, smile and wave.
5. How many buttons will mq2mybuttons have in MQNext? I'd like to start planning how I'll spend them
The direct answer to your question is 12, but the eventual answer is "as many as you want." One of the benefits of splitting out TargetInfo/GroupInfo/XTarInfo into their own respective plugins and the cleanup I did there was that I got reacquainted with the EQ UI. The place where I was stuck on MyButtons was that I didn't know how to paginate and my next goal for evolution of that (if someone doesn't beat me to it) is to allow you to specify number of pages and number of buttons per page. The way MMO does it, I think is they just give you something like 30 buttons. But I don't personally want 30 buttons all on one page so I'd been holding out making changes to the number of buttons (other than I had increased it to 12 from 10 when I brought it back to life). Button pagination isn't something we've done in plugins before, so I didn't have an example to work off of, but I have a good idea of how to do it now.
6. Will MQ2 and MQNext coexist or will Next completely replace MQ2 for the entire MQ community (including the other guys)?
That's really up to everyone else. We did not envision the two coexisting since there's really no reason for the current iteration of MQ2 to exist once we've released. But MMO has full access to the source and I know Xeniaz has been working on updating their plugins to work with Next (and they also have access to every plugin we've updated for Next as a head start -- since everything we've updated is open source).
RedGuides has built up my trust and Red being part of the counsel overseeing this plugin is all the certification I need. A summary explanation of what the plugin does, what it doesn't do, and Red giving the thumbs up saying that is accurate, is good for me...<snip>...When there is a council of four developers plus Red that have control of that plugin's replacement, then that's a lot of people who have to collaborate and agree to do something shady.
While that probably would have been enough before the IC debacle and I certainly trust Redbot's judgement myself -- he'll probably tell you himself he's not a coder. I'd like to think he could probably pick out "Oh, and we're sending your information somewhere else" but the fact of the matter is that the community suffered a breach of trust. There are varying levels of "current trust" and we're trading on our existing reputations, which, unfortunately was what eqmule was also trading on. So I think it warrants an indisputable approach at this point. Hopefully others feel the same way you do, but until everyone feels comfortable again I think we owe it to the community to raise that level of trust.
I have a question related to the extended functionality and ability to run multiple luacros that control behavior. Previous design protocols meant that Users had to load plugins, some closed source, to manage multiple processes.
Does the inclusion of mean that the VV compile has extraneous plugins (both free and paid) that could be demade into luacros and run simultaneously?
I sort of answered this above, but I didn't want to leave you out of my quoting spree. MacroQuest was originally designed around the idea that automation was done in macros and functionality was extended through plugins. But there are things like MQ2Nav that would be extremely hard to do even in
Lua. I'm hoping opening up
Lua will spur development from people wanting to write "quick utilities" instead of "full fledged run your toon and wash dishes" macros (not that there's anything wrong with that too). The plugins you listed could definitely all be done in
Lua, and in fact, most of the plugins we have right now that perform automation can be done in
Lua since the impetus for doing them in plugins was just "simultaneous operation" rather than any need for C features. However, whether someone will is really up to the community.
Stop trying to make luacros a thing, use it for a cough syrup brand! 
