MQ2 Latest Release - February 15, 2004

MacroFiend · Post by **MacroFiend** » Tue Nov 18, 2003 10:29 am

I love having MQ2 plugin driven. To that end, I would like to suggest a not-so-minor change. Right now, the core MQ2 functions are in MQ2Main.dll which is great ... except if you want to recompile the main library to update core functions. You have to /unload MQ2, close MacroQuest2.exe and then copy the new version over. My suggestion is this:

Make MacroQuest2.exe inject a DLL that only has the plugin handler and abstract framework functions (addcommand/removecommand etc). So initially, all it adds to MQ is the /plugin command, reads the INI file and loads any auto-start plugins. It could then load ... MQ2Commands.dll or MQ2Script.dll (new name for the existing MQ2Main.dll).

This would let us /plugin mq2main unload so we can recompile the core scripting/command interface without unloading the entire framework and closing the tray exe.

tehHax0r · Post by **tehHax0r** » Tue Nov 18, 2003 11:17 am

If we made the scripting into a separate dll, we could create a manager class to initiate instances of macros.. allowing multiple macros to run.

of course.. this would probably break everything else hehe
not to mention the coding nightmare it would be

auth · Post by **auth** » Tue Nov 18, 2003 11:21 am

MQ2Telnet loads just fine, but when I try to unload it, EQ freezes.

Teh_ish · Post by **Teh_ish** » Tue Nov 18, 2003 1:58 pm

MacroFiend wrote:I love having MQ2 plugin driven. To that end, I would like to suggest a not-so-minor change. Right now, the core MQ2 functions are in MQ2Main.dll which is great ... except if you want to recompile the main library to update core functions. You have to /unload MQ2, close MacroQuest2.exe and then copy the new version over. My suggestion is this:

Make MacroQuest2.exe inject a DLL that only has the plugin handler and abstract framework functions (addcommand/removecommand etc). So initially, all it adds to MQ is the /plugin command, reads the INI file and loads any auto-start plugins. It could then load ... MQ2Commands.dll or MQ2Script.dll (new name for the existing MQ2Main.dll).

This would let us /plugin mq2main unload so we can recompile the core scripting/command interface without unloading the entire framework and closing the tray exe.

I second this. That would be such a great asset to not have to go through relogging to make changes.

Lax · Post by **Lax** » Tue Nov 18, 2003 10:31 pm

While I agree with the idea that it would be easier to compile while playing, let's try not to overdo the plugin idea. I mean, is it really worth it to make another separation? It would require 2 separate libraries for every plugin to include and more preprocessor definitions etc, and all just so that you dont have to unload and close macroquest.exe to compile... personally I dont mind that much having to unload and close the exe. And with the existing modular concept behind MQ2, you generally won't need to touch MQ2Main.dll. I give a "no" vote to the idea, simply because the benefits are very limited for the amount of ass pain.

Also about running 2 macros, do you really think it's a good idea to run 2 macros? Think about it. One's executing one command, the other is executing another... what if they both try to cast at the same time? etc... I would say if you need to run 2 macros, at least one of them is doing something that should just be made into a plugin. Macros should stay mutually exclusive IMHO.

And.. you dont need to relog, ish. /unload, close macroquest... then to reload just start macroquest again.

MacroFiend · Post by **MacroFiend** » Wed Nov 19, 2003 1:13 am

You wouldn't need to have extra preprocessor commands or include 2 seperate libraries if it was done well.

If the MQ2Main.dll (for example) exposed all the EQ structures and definitions, then MQ2Script.dll (also an example) would just contain the PMP and command definitions.

All the other libraries would still import the MQ2 structs and globals for core operation.

IMO, it is a new level of abstraction from EQ that would enable rapid development of new core commands as well as allow the users more control over their MQ environment.

Here's an example: A player doesn't want to completely and blatantly violate the EULA (whose essense is "the use of any program that alters gameplay to offer an unfair advantage") ... they just want to chat via telnet and use the frame limiter.

Without the seperation of commands from core library, there is no way that they can do this right now even with the plugin design. They could only load the framelimiter and telnet but they still have all the core MQ2 functions that are there begging to get them in trouble.

That is a fairly extreme example but it illustrates the point.

I could even see going 1 step further (which even I think would be overboard) and say that the PMP and the commands could be individual libraries. MQ2Commands.dll and MQ2Variables.dll or something. So that someone who only wanted the UI embellishments could just use the MQ2variables and the MQ2UI libraries.

Overall, this might not be the best idea but I think that it is a good one to explore.

tehHax0r · Post by **tehHax0r** » Wed Nov 19, 2003 2:09 am

Just putting out an idea on how one would accomplish such a thing if they wanted. I for one would not really want to be able to run two macros at once, the problems would far surpass any advantages.

Lax · Post by **Lax** » Wed Nov 19, 2003 2:38 am

What I was referring to was the problem with having the injector, the "plugin loader", and then the MQ2Main.. The plugin loader would have to handle detours and plugins, and also commands if you wanted to reload MQ2Main on the fly. MQ2Main could hide it and it could work just fine, but trying to separate plugins from MQ2Main would not... read on.

I really doubt that anyone in their right mind is going to use MQ2 with or without extra commands and think theyre being any less of a violator. EQCPU download takes care of giving the framerate limiter to those that don't want to feel like they're cheating.. and telnet.. well.. no comment there I guess. Besides, these plugins require the API to function. Telnet requires some detours, and we can't separate that without breaking everything else -- it absolutely must have the chat hook or it will not work... and if that's not being taken care of by MQ2Main it will conflict with other chat plugins. The FPS limiter requires the process game events hook, and uses display functions. We'd literally have to move all of the functionality of MQ2Main to this other DLL just so that things would work.

I'm not seeing how it would enable rapid development of new core commands... you can develop new stuff from within a plugin and then move it to the api if necessary. Really there's almost no reason to develop directly in MQ2Main unless you're modifying something that already exists.

I'm also going to have to say though that I'm not really in favor of splitting API functionality that plugins need into other dlls. We could do it but it's just going to be extra overhead to satisfy about 4 people who would unload them

Lax · Post by **Lax** » Wed Nov 19, 2003 11:13 pm

Zip updated. Added makefile to the list of files mkplugin makes for new plugins. Added safeguard to MQ2FPS plugin if pScreenX or pScreenY are null. Added MQ2-API.chm, the MQ2 API documentation. You can open this directly with windows to find some help. It needs a lot of work yet, but it's a good start.

Lax · Post by **Lax** » Thu Nov 20, 2003 4:01 am

Zip updated.

- MacroQuest program will no longer use loadlibrary, it loads our library directly.
- The version number is now stored in MQ2Main.h as the top line, and not in macroquest.ini. When compiled it becomes a global variable. Comparing the global variable gszVersion with the #define in MQ2Main.h will cause the tray icon tooltip to suggest recompiling if necessary.
- Removed EQADDR_SLOTLIST, which is now ppInvSlotMgr/pInvSlotMgr
- Fixed MQ2Telnet crashes (for real)

Lax · Post by **Lax** » Thu Nov 20, 2003 5:13 am

Zip updated.

- Added DebugSpewNoFile. Refuses to debugspew to file even if the option is on. This is to be used for very repetitive debug spewing. It's useful for when you have a debugger attached. Switched every macro parsing debug spew to use this.
- Fixed project dependencies (DKAA fixed the .deps, I fixed the .dsw)

Note: Telnet is still broken. DKAA is working on it.

ap50 · Post by **ap50** » Thu Nov 20, 2003 7:50 am

Lax wrote:http://macroquest2.com/?p=download

If you don't want to use the chat window plugin, you can use the default chat plugin (or both).
/plugin mq2chat
loads the default chat plugin
then you can
/plugin mq2chatwnd unload
and you're good to go.

Ok, just been having a look at this, I can unload the new chat window, but for the life of me, I cannot return to my main chat window as recipient of MQ output..

I'm guessing /filter MQChat off is no more, as it doesn't seem to do anything either.

I just want my mq output in my main window, even in 1280x1024, I don't want another window on my screen

papiraul · Post by **papiraul** » Thu Nov 20, 2003 8:42 am

Yes it will,, just check how your alias is configured..

I bet you are using / OR /w
Try using /who instead

Lax · Post by **Lax** » Thu Nov 20, 2003 11:04 am

AP50 I cant believe you quoted the procedure for making the main chat window the chat output window and then said you have no idea how to do it. MQ2Chat and MQ2ChatWnd are 2 different plugins. MQ2Chat goes to main window. MQ2ChatWnd goes to new chat window.

Mckorr · Post by **Mckorr** » Thu Nov 20, 2003 12:44 pm

Clarification: If you want MQ output to go to the main chat window, load MQ2Chat. If you want it to go to the MQ chat window, load MQ2ChatWnd. You don't need both, just one or the other. You do need ONE of these plugins if you aren't getting your MQ message elsewhere, telnet for example.

MQ2 Latest Release - February 15, 2004

Telnet

Re: MQ2 Stable Beta Release