I modded MQ last night to pop up a (plain old) console window and pipe all MQ output to that window. I also modified MQ so that output would be "twinned" -- both normal EQ functions and MQ functions will spew, but if you set /filter macros none, the MQ text ONLY goes to the console window.
Once you insert a console window (I do it in the function where we hook the commands; otherwise you could potentially end up with every app in the system spawning a command window :), it's simplicity itself to hook the MQ output to the console. Printf, baby.
Works like a champ. The ONLY MQ spew that still goes into EQ is the "MacroQuest is active" thingy at the beginning, and I think that's because we spew that before we have a chance to set the filter (heh, just realized that on the way to work this morning). Once I mod that out, MQ will be TOTALLY stealth. You can do a /who NPC and the main EQ window will show NOTHING, but the console window shows the nice spiffy MQ /who list. Eat your heart out, GM's.
Next step: make the output remotable, and allow remote input too (so that I don't HAVE to use EQW). That will take an ounce of thought because I can't just use the simple AllocConsole and stdio calls. Not THAT hard though, since the WriteChatColor function is the gateway for all MQ text spew.
I have NOT been getting enough sleep lately.
Oh, btw, if people haven't guessed yet, I'm doing my dev work under EQW.
Console Mod Complete
Moderator: MacroQuest Developers
Oh, forgot to add that I added a switch too, /filter conoutecho [on|off]
This will take NORMAL chat window text (through the chat detour) and echo it to the console window or not (depending upon the setting).
If you are JUST looking at the console window, it's useful to see the normal chat lines. IE, if Bozo The`Clown sends me a tell, unless I have /filter conoutecho on, I won't see it in the console window -- only the EQ window (only MQ-generated text goes to the console window unless /fiter conoutecho is on). Of course, when you can actually SEE the EQ spew, it's annoying to have to ALSO see it duplicated in your MQ spew window. Hence the switch.
---
I need to read about CVS so I can submit these changes. We use a source-control system here at work, but it's very different...
---
Work for today:
* further refine the console so that it's pluggable with other methods of output (IE, Plaz's original idea of a gui console, or redirect through a socket or named pipe)
* come up with a clever method of redirecting input. I'm THINKING of just echoing WM_KEYDOWN and KEYUP events directly through to the client, when it's "hooked". The benefit of this is that you could actually "drive" the client (including events that require key messages as opposed to just WM_CHAR streams) from the remote console. But I want to brainstorm on this to figure out the cleanest idea. I clearly can't do this with the text console I'm using now, because STDIN is too gimpy for this. Hence the need to make the remote input/output method pluggable.
* PRIVATE MOD: hook the /loc memory location and the spawn list, figure out the ShowEQ map format, and do a GUI ShowEQ based upon the in-memory /loc and spawn information. Not going to try to duplicate ShowEQ, just do the map and "radar" display. Obviously this is going to be a very private mod, because integrating ShowEQ and MQ would be a fabulous way to get MQ nerfed into the stone age. I've been wanting to do this for a while, but the guys over on the SEQ boards have conveniently stuffed all of their decrypt functions into a linux lib, and I've been too lazy to figure out how to convert that lib into a VC-linkable format. One benefit is that since the app won't have to do any encrypt/decrypt, it should be MUCH faster...
* resolve, once and for all, my dilemma over how I'm going to thread Perl. I've come up with a few solutions, but none of them are pleasant. Once this is resolved, the real work of hooking Perl in gets started. I needed to have the console working so that my test spew in Perl will go undetected by GM's.
* Perl integration work
I'm thinking of modding MQ so that all of the memory read, chat output, and keyboard/mouse input functions go through a DLL api.
The benefit of this is that add-on's can be written as separate self-contained DLL's. This makes testing MUCHO easier, and allows custom DLL's to be swapped in and out. One DLL could just encapsulate the existing macro functionality. Another DLL could add Perl macro functionality. Another DLL could be my private map/radar module. Etc. DLL's could just register interest in changes in any of the memory locations. We'd have a dedicated monitor thread that would send notifications to the chained DLL's when something changed, and when something DID change, it would go down the list of registered DLL's and call callbacks in them. Mouse and keyboard input would be queued (to avoid concurrency issues). Maybe mouse/keyboard input could be transacted, so that you wouldn't get one DLL telling the mouse to go to loc X,Y, then click, a second DLL saying to go to loc Z, Z', then click, and get those interleaved so the mouse goes to X,Y, then Z,Z', then click, then click. That Would Be Bad.
Hmm, must think about this.
This will take NORMAL chat window text (through the chat detour) and echo it to the console window or not (depending upon the setting).
If you are JUST looking at the console window, it's useful to see the normal chat lines. IE, if Bozo The`Clown sends me a tell, unless I have /filter conoutecho on, I won't see it in the console window -- only the EQ window (only MQ-generated text goes to the console window unless /fiter conoutecho is on). Of course, when you can actually SEE the EQ spew, it's annoying to have to ALSO see it duplicated in your MQ spew window. Hence the switch.
---
I need to read about CVS so I can submit these changes. We use a source-control system here at work, but it's very different...
---
Work for today:
* further refine the console so that it's pluggable with other methods of output (IE, Plaz's original idea of a gui console, or redirect through a socket or named pipe)
* come up with a clever method of redirecting input. I'm THINKING of just echoing WM_KEYDOWN and KEYUP events directly through to the client, when it's "hooked". The benefit of this is that you could actually "drive" the client (including events that require key messages as opposed to just WM_CHAR streams) from the remote console. But I want to brainstorm on this to figure out the cleanest idea. I clearly can't do this with the text console I'm using now, because STDIN is too gimpy for this. Hence the need to make the remote input/output method pluggable.
* PRIVATE MOD: hook the /loc memory location and the spawn list, figure out the ShowEQ map format, and do a GUI ShowEQ based upon the in-memory /loc and spawn information. Not going to try to duplicate ShowEQ, just do the map and "radar" display. Obviously this is going to be a very private mod, because integrating ShowEQ and MQ would be a fabulous way to get MQ nerfed into the stone age. I've been wanting to do this for a while, but the guys over on the SEQ boards have conveniently stuffed all of their decrypt functions into a linux lib, and I've been too lazy to figure out how to convert that lib into a VC-linkable format. One benefit is that since the app won't have to do any encrypt/decrypt, it should be MUCH faster...
* resolve, once and for all, my dilemma over how I'm going to thread Perl. I've come up with a few solutions, but none of them are pleasant. Once this is resolved, the real work of hooking Perl in gets started. I needed to have the console working so that my test spew in Perl will go undetected by GM's.
* Perl integration work
I'm thinking of modding MQ so that all of the memory read, chat output, and keyboard/mouse input functions go through a DLL api.
The benefit of this is that add-on's can be written as separate self-contained DLL's. This makes testing MUCHO easier, and allows custom DLL's to be swapped in and out. One DLL could just encapsulate the existing macro functionality. Another DLL could add Perl macro functionality. Another DLL could be my private map/radar module. Etc. DLL's could just register interest in changes in any of the memory locations. We'd have a dedicated monitor thread that would send notifications to the chained DLL's when something changed, and when something DID change, it would go down the list of registered DLL's and call callbacks in them. Mouse and keyboard input would be queued (to avoid concurrency issues). Maybe mouse/keyboard input could be transacted, so that you wouldn't get one DLL telling the mouse to go to loc X,Y, then click, a second DLL saying to go to loc Z, Z', then click, and get those interleaved so the mouse goes to X,Y, then Z,Z', then click, then click. That Would Be Bad.
Hmm, must think about this.
-
TetsuoAkira
- orc pawn
- Posts: 28
- Joined: Tue Jul 09, 2002 10:06 pm
I'll try to get online with that tonight.
All of the work I've done so far has been on my own private Idaho. I'm going to climb the CVS learning curve today, and I'll dig up my old IRC client. What's the channel?
I totally agree that we should all stay in synch on the dev work. Plus I have some questions about just how easy we should make all of this -- since there is unlimited potential for expansion, we could end up with an unattended macroer's dream. Do we want to not add a feature just because it might support unattended macroing? Or do we add it and "let the buyer beware?" I'm never in favor of intentionally gimping my code, but if it's gonna get us all nerfed (or banned), I'll do it :)
All of the work I've done so far has been on my own private Idaho. I'm going to climb the CVS learning curve today, and I'll dig up my old IRC client. What's the channel?
I totally agree that we should all stay in synch on the dev work. Plus I have some questions about just how easy we should make all of this -- since there is unlimited potential for expansion, we could end up with an unattended macroer's dream. Do we want to not add a feature just because it might support unattended macroing? Or do we add it and "let the buyer beware?" I'm never in favor of intentionally gimping my code, but if it's gonna get us all nerfed (or banned), I'll do it :)
-
theafkxper
- a hill giant
- Posts: 207
- Joined: Sun Sep 08, 2002 6:41 pm
Salutations,
I should hope that something like this does NOT go public to anyone past the person who coded it as it may lead to MQ being the next winSEQ and that would be BAD!theafkxper wrote:any chance of us outsiders getting the radar, maybe not a map, but something that showed an overhead list of spawns withing like 600 range or so?
- afk
Yeah absolutely... The radar thing is pretty far down on the list anyway since I already have a working SEQ install... It would just be to free up a box. No way in hell it would be released. This isn't to be snobbish or selfish, but because MQ would get nerfed to infinity about the day after it was released. If you do a little GUI coding and think about the way that MQ reads the EQ memory locations, you can easily "roll your own" -- but that's about as far as I"m gonna go with that one.
Focusing on the improved scripting engine and framework for now...
Focusing on the improved scripting engine and framework for now...
-
|23374|2|)
- orc pawn
- Posts: 16
- Joined: Sat Sep 28, 2002 5:14 pm
- Location: San Jose
- Contact:
Console Mod
so... where can we get this console mod.. the title says "Console Mod Complete" so does that mean we can get it...?
waiting for the boat is so fun
|-------||------|
|__________//\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
|-------||------|
|__________//\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
I kinda like the radar idea... NOT a SEQ type radar, I don't care what spawns are nearby, I just want to be able to travel without going over a hill and running smack into a big ugly mob.
I don't even want a gimped Track, I don't want cons or names or levels or anything, just a Metal Gear Solid type of radar that maybe shows spawns nearby and which direction they are facing. I just want to be able to walk to Thurg from GD rings with my wizard like everyone else, except without being eaten alive by the wurms, bear/penguin things, and those tizmacs along the way. I tried incorperating that into a macro using /face and /face away, but I ended up just making a macro that walks me around aimlessly but aviods all mobs. I don't get killed, but I don't get where I'm going either.
I was trying to be clever with that macro, considering the relatively slow speed you can make /face and /face away work, I was going to keep facing the basic loc of thurg, but also /target the nearest NPC, con it, and if Event_FactionMsg shows it cons hostile, /face away, walk for a bit, /face loc Thurg, and keep going, however, I put my check too often, and while every now and then I'd get there, most of the time I'd be wandering all over the place, OR I faced Thurg too early and walked right back to the mob.
A Metal Gear Solid radar would solve that problem, and I don't think it would really piss off Verant all that much, since even simple Track has twice the functionality, all this does is prevent stupid accidents that i have to put up with cause I play a wizard and not a warrior. A warrior can deal with surprise fights, but my wizard is screwed if it hits me first.
Any chance of this happening?
- icon
I don't even want a gimped Track, I don't want cons or names or levels or anything, just a Metal Gear Solid type of radar that maybe shows spawns nearby and which direction they are facing. I just want to be able to walk to Thurg from GD rings with my wizard like everyone else, except without being eaten alive by the wurms, bear/penguin things, and those tizmacs along the way. I tried incorperating that into a macro using /face and /face away, but I ended up just making a macro that walks me around aimlessly but aviods all mobs. I don't get killed, but I don't get where I'm going either.
I was trying to be clever with that macro, considering the relatively slow speed you can make /face and /face away work, I was going to keep facing the basic loc of thurg, but also /target the nearest NPC, con it, and if Event_FactionMsg shows it cons hostile, /face away, walk for a bit, /face loc Thurg, and keep going, however, I put my check too often, and while every now and then I'd get there, most of the time I'd be wandering all over the place, OR I faced Thurg too early and walked right back to the mob.
A Metal Gear Solid radar would solve that problem, and I don't think it would really piss off Verant all that much, since even simple Track has twice the functionality, all this does is prevent stupid accidents that i have to put up with cause I play a wizard and not a warrior. A warrior can deal with surprise fights, but my wizard is screwed if it hits me first.
Any chance of this happening?
- icon
In memory of [b][color=darkblue]MasTerKeyZ[/b][/color].