IRL - EQ Window management (development discussion Non Macro / MQ2) (1 Viewer)

[devestator]

Hello All,
Some of you may remember me from a while back. I've been away from the MQ2 scene for a while. Spent a while not playing EQ and then did a stent on truebox servers so haven't really been messing with anything. But just recently I've started playing around with MQ2 again.

For those who used to know me (dunno how many are here on RG since I used to frequent another site more regularly), and knew me to do custom work, I just want to say up front that I don't plan on doing any of that. I don't have the time these days to properly support anything like that. So, my contributions will mostly be contributing to other projects or just helping others where I can. If I end up getting level 2 access here at some point, I'll look into what projects I might could help out! If I do get time to develop new stuff, it'll get publicly released (or level 2) and might not get maintained regularly, fair warning lol

All that said, playing around with things again has scratched an itch I've been missing for a while on little hobby projects. And this post is mostly concerning one of those. This is not strictly a MQ2 project, but I do see where there could be some useful crosstalk with a plugin perhaps. That project is a EQ Window Manager. I know this isn't anything new, WinEQ2 and ISBoxer have both done the job for a long time. But, I wanted to work on my own because I could also see some nice improvements made combining them with direct support in MQ2 to make logins smoother and window management from within EQ itself. Even things like macro management and such baked in to just try and streamline multiboxing and make it even easier than it already is with the outstanding things people have already created.

So, I dusted off my old project a couple of days ago and have been playing around with it again, refreshing myself on where I was. And, now I remember when I had stopped on it I had hit a little bit of a wall. I know development and such pretty well there is no problem there, my problem is just my limited knowledge in the area of game development and win32api and such in general. I have successfully written a tool that will allow me to full screen emulate eq windows and position them where I want. Including tiling support like WinEQ2 used to do and hotkeys to activate windows and such. The problem I've run into is with input to the windows.

First input problem is with the mouse if the window is scaled so that it's not actually running at it's full height / width (this is a setup I generally like to run with my boxes tiled so I can see all of them on a secondary monitor at the same time). The graphics and all are perfectly fine, but EQ still tracks the mouse as if it's running full size. I'm pretty confident I could get around this if I actually changed EQs resolution to match the scaled size. But I don't want to do that, mainly because I want to preserve the UI settings lol. Also because I know that isn't necessary from seeing other software do it. I cannot figure out how to get around this myself though. At first I thought maybe it was because of mouse messaging events and EQ thinking it's running full size based on the resolution, so still mapping the mouse clicks as if it were. I went down a rabbit hole of Low level mouse hooks, trying to reposition the mouse to scale. Tried blocking the original click from processing through further hooks creating a new click at the scaled location, things like that. But none of that seems to work. EQ seems to be capturing it's inputs in some different manner. If I block a mouse click for example, I can block it everywhere, except EQ. EQ will still pick up the click. From what I've read Low level mouse hooks are supposed to be processed from the most recent hook to the oldest, so I'm not sure how EQ is capturing the mouse info. It must not be through a system low level hook. That is why I'm stuck, at this point I just don't even know what to search for to try and make some headway on this. The only guess I have is that WinEQ and ISBoxer achieve it by creating the EQ process as a child process to their own programs. But even then I'm not sure what method they use... unless maybe it's simply a local mouse event instead of the global one that I'm playing with.

And then there is the keyboard input. I know for example ISBoxer can send keypresses to a specific EQ window, even when it is in the background. And again here, I'm entirely unsure of what it uses to do that. I think I remember reading a long long time ago about EQ using DirectInput or something like that. Maybe there is more research to be done down that road. But, the only way I've been able to successfully execute a keypress in EQ is if it is the foreground window. Which is not very helpful for boxing. Not that this is a big deal, can get around this via MQ2. But I feel like if I could figure out the keyboard, the mouse would probably be similar solution. I'm not trying to make this a replacement for MQ2 or anything, but do want to be able to alt tab to a boxed window and click hotkeys / gems / etc without having to rescale it every time.

Figured I'd post about this here and see if maybe one of the other devs around here that are more directly involved in EQ has some tidbits they'd be willing to share. A nudge in the right direction or something. Finding information specifically on EQ is too niche so my general searching isn't really yielding any results haha. I haven't tried to look at what MQ2 itself does to do keypresses and such yet. Maybe I should lol! I've just always felt like MQ2 probably does it differently with injecting into the EQ Process and all. Something I want to try to avoid if I can (but maybe I can't... maybe that is how it has to be done. hopefully one day I'll know the answer to that).

Anyway, I welcome any discussion anyone has on this! If I do ever get this working and others think they'd find it useful, I'll be happy to share it. And I hope to be able to start helping out contributing elsewhere again soon!

 

[ChatWithThisName]

Hello All,
Some of you may remember me from a while back. I've been away from the MQ2 scene for a while. Spent a while not playing EQ and then did a stent on truebox servers so haven't really been messing with anything. But just recently I've started playing around with MQ2 again.

For those who used to know me (dunno how many are here on RG since I used to frequent another site more regularly), and knew me to do custom work, I just want to say up front that I don't plan on doing any of that. I don't have the time these days to properly support anything like that. So, my contributions will mostly be contributing to other projects or just helping others where I can. If I end up getting level 2 access here at some point, I'll look into what projects I might could help out! If I do get time to develop new stuff, it'll get publicly released (or level 2) and might not get maintained regularly, fair warning lol

All that said, playing around with things again has scratched an itch I've been missing for a while on little hobby projects. And this post is mostly concerning one of those. This is not strictly a MQ2 project, but I do see where there could be some useful crosstalk with a plugin perhaps. That project is a EQ Window Manager. I know this isn't anything new, WinEQ2 and ISBoxer have both done the job for a long time. But, I wanted to work on my own because I could also see some nice improvements made combining them with direct support in MQ2 to make logins smoother and window management from within EQ itself. Even things like macro management and such baked in to just try and streamline multiboxing and make it even easier than it already is with the outstanding things people have already created.

So, I dusted off my old project a couple of days ago and have been playing around with it again, refreshing myself on where I was. And, now I remember when I had stopped on it I had hit a little bit of a wall. I know development and such pretty well there is no problem there, my problem is just my limited knowledge in the area of game development and win32api and such in general. I have successfully written a tool that will allow me to full screen emulate eq windows and position them where I want. Including tiling support like WinEQ2 used to do and hotkeys to activate windows and such. The problem I've run into is with input to the windows.

First input problem is with the mouse if the window is scaled so that it's not actually running at it's full height / width (this is a setup I generally like to run with my boxes tiled so I can see all of them on a secondary monitor at the same time). The graphics and all are perfectly fine, but EQ still tracks the mouse as if it's running full size. I'm pretty confident I could get around this if I actually changed EQs resolution to match the scaled size. But I don't want to do that, mainly because I want to preserve the UI settings lol. Also because I know that isn't necessary from seeing other software do it. I cannot figure out how to get around this myself though. At first I thought maybe it was because of mouse messaging events and EQ thinking it's running full size based on the resolution, so still mapping the mouse clicks as if it were. I went down a rabbit hole of Low level mouse hooks, trying to reposition the mouse to scale. Tried blocking the original click from processing through further hooks creating a new click at the scaled location, things like that. But none of that seems to work. EQ seems to be capturing it's inputs in some different manner. If I block a mouse click for example, I can block it everywhere, except EQ. EQ will still pick up the click. From what I've read Low level mouse hooks are supposed to be processed from the most recent hook to the oldest, so I'm not sure how EQ is capturing the mouse info. It must not be through a system low level hook. That is why I'm stuck, at this point I just don't even know what to search for to try and make some headway on this. The only guess I have is that WinEQ and ISBoxer achieve it by creating the EQ process as a child process to their own programs. But even then I'm not sure what method they use... unless maybe it's simply a local mouse event instead of the global one that I'm playing with.

And then there is the keyboard input. I know for example ISBoxer can send keypresses to a specific EQ window, even when it is in the background. And again here, I'm entirely unsure of what it uses to do that. I think I remember reading a long long time ago about EQ using DirectInput or something like that. Maybe there is more research to be done down that road. But, the only way I've been able to successfully execute a keypress in EQ is if it is the foreground window. Which is not very helpful for boxing. Not that this is a big deal, can get around this via MQ2. But I feel like if I could figure out the keyboard, the mouse would probably be similar solution. I'm not trying to make this a replacement for MQ2 or anything, but do want to be able to alt tab to a boxed window and click hotkeys / gems / etc without having to rescale it every time.

Figured I'd post about this here and see if maybe one of the other devs around here that are more directly involved in EQ has some tidbits they'd be willing to share. A nudge in the right direction or something. Finding information specifically on EQ is too niche so my general searching isn't really yielding any results haha. I haven't tried to look at what MQ2 itself does to do keypresses and such yet. Maybe I should lol! I've just always felt like MQ2 probably does it differently with injecting into the EQ Process and all. Something I want to try to avoid if I can (but maybe I can't... maybe that is how it has to be done. hopefully one day I'll know the answer to that).

Anyway, I welcome any discussion anyone has on this! If I do ever get this working and others think they'd find it useful, I'll be happy to share it. And I hope to be able to start helping out contributing elsewhere again soon!

Sounds like you should try joining the discord for RG and poke your head into the coding channel. Lots of help available on redguides, and I think something like this might be better served in the coding channel. While I'm sure the forums would be just fine I think you'll be able to get better assistance in the channel. I've gifted you level 2 so you can get to the channel. You'll want to goto the "Chat" link in the top of the forums header links and link your discord to the RG account.

 

[jayah]

Welcome back ... miss some of the pulling functions you had in your macros back in the day ... used most ( if not all ) of your paid macros back then.

Good to see you back.

 

[orbitz]

Hey Devestator....good to see you back playing around with things.

 

[Doc James]

Welcome back!

 

[brilucdestiny]

Hello All,
Some of you may remember me from a while back. I've been away from the MQ2 scene for a while. Spent a while not playing EQ and then did a stent on truebox servers so haven't really been messing with anything. But just recently I've started playing around with MQ2 again.

For those who used to know me (dunno how many are here on RG since I used to frequent another site more regularly), and knew me to do custom work, I just want to say up front that I don't plan on doing any of that. I don't have the time these days to properly support anything like that. So, my contributions will mostly be contributing to other projects or just helping others where I can. If I end up getting level 2 access here at some point, I'll look into what projects I might could help out! If I do get time to develop new stuff, it'll get publicly released (or level 2) and might not get maintained regularly, fair warning lol

All that said, playing around with things again has scratched an itch I've been missing for a while on little hobby projects. And this post is mostly concerning one of those. This is not strictly a MQ2 project, but I do see where there could be some useful crosstalk with a plugin perhaps. That project is a EQ Window Manager. I know this isn't anything new, WinEQ2 and ISBoxer have both done the job for a long time. But, I wanted to work on my own because I could also see some nice improvements made combining them with direct support in MQ2 to make logins smoother and window management from within EQ itself. Even things like macro management and such baked in to just try and streamline multiboxing and make it even easier than it already is with the outstanding things people have already created.

So, I dusted off my old project a couple of days ago and have been playing around with it again, refreshing myself on where I was. And, now I remember when I had stopped on it I had hit a little bit of a wall. I know development and such pretty well there is no problem there, my problem is just my limited knowledge in the area of game development and win32api and such in general. I have successfully written a tool that will allow me to full screen emulate eq windows and position them where I want. Including tiling support like WinEQ2 used to do and hotkeys to activate windows and such. The problem I've run into is with input to the windows.

First input problem is with the mouse if the window is scaled so that it's not actually running at it's full height / width (this is a setup I generally like to run with my boxes tiled so I can see all of them on a secondary monitor at the same time). The graphics and all are perfectly fine, but EQ still tracks the mouse as if it's running full size. I'm pretty confident I could get around this if I actually changed EQs resolution to match the scaled size. But I don't want to do that, mainly because I want to preserve the UI settings lol. Also because I know that isn't necessary from seeing other software do it. I cannot figure out how to get around this myself though. At first I thought maybe it was because of mouse messaging events and EQ thinking it's running full size based on the resolution, so still mapping the mouse clicks as if it were. I went down a rabbit hole of Low level mouse hooks, trying to reposition the mouse to scale. Tried blocking the original click from processing through further hooks creating a new click at the scaled location, things like that. But none of that seems to work. EQ seems to be capturing it's inputs in some different manner. If I block a mouse click for example, I can block it everywhere, except EQ. EQ will still pick up the click. From what I've read Low level mouse hooks are supposed to be processed from the most recent hook to the oldest, so I'm not sure how EQ is capturing the mouse info. It must not be through a system low level hook. That is why I'm stuck, at this point I just don't even know what to search for to try and make some headway on this. The only guess I have is that WinEQ and ISBoxer achieve it by creating the EQ process as a child process to their own programs. But even then I'm not sure what method they use... unless maybe it's simply a local mouse event instead of the global one that I'm playing with.

And then there is the keyboard input. I know for example ISBoxer can send keypresses to a specific EQ window, even when it is in the background. And again here, I'm entirely unsure of what it uses to do that. I think I remember reading a long long time ago about EQ using DirectInput or something like that. Maybe there is more research to be done down that road. But, the only way I've been able to successfully execute a keypress in EQ is if it is the foreground window. Which is not very helpful for boxing. Not that this is a big deal, can get around this via MQ2. But I feel like if I could figure out the keyboard, the mouse would probably be similar solution. I'm not trying to make this a replacement for MQ2 or anything, but do want to be able to alt tab to a boxed window and click hotkeys / gems / etc without having to rescale it every time.

Figured I'd post about this here and see if maybe one of the other devs around here that are more directly involved in EQ has some tidbits they'd be willing to share. A nudge in the right direction or something. Finding information specifically on EQ is too niche so my general searching isn't really yielding any results haha. I haven't tried to look at what MQ2 itself does to do keypresses and such yet. Maybe I should lol! I've just always felt like MQ2 probably does it differently with injecting into the EQ Process and all. Something I want to try to avoid if I can (but maybe I can't... maybe that is how it has to be done. hopefully one day I'll know the answer to that).

Anyway, I welcome any discussion anyone has on this! If I do ever get this working and others think they'd find it useful, I'll be happy to share it. And I hope to be able to start helping out contributing elsewhere again soon!

I too have started looking at MQ to try to understand how it is truly working. I started off just compiling the codes manually before redguides. It was such a hassle having to do that every single patch because MQ doesn't let you run unless it's full patched.

From what I can see in the code, this is what I think it does: (other seasoned developers feel free to chime in)

1) There's an injection process to the EQ.exe
2) Once there, it invoked the machine instructions directly by using a code offset address. (Yes, I even went into the deep end trying to understand things I previously never do in my professional job). Once you have an address offset, you can also retrieve whatever you need without an injection to the .exe. (I am still trying to figure it out. This is because it depends on other factors such as little or bit endian, etc to really read the data correctly externally.) Technically speaking , I can build a solution without ever injecting the code as long as i have access to the RAM to read the world data.
3) It uses piping for communication.

I was working on an MQ2 Lite prototype that does not requires injection and is more like an 'observer' pattern rather than an intrusive entity. It has its limitation but I was at least able to push keyboard events to my clean EQ window. If you want, we can work together to share our understanding of the code.

Due to work, I too have put it aside. Now that there are wave bans happening, I think we all need to work together for a much more robust version of MQ so that it is not as obvious. Example, adding a random timer to the actions and also modify the traveling path slightly. I realize my capacity is limited as I do not have unlimited time nor resources.

I am Lavenius#5299 on discord if you want to reach out.

 

[Sic]

Now that there are wave bans happening,

nothing has *really* changed here in the last few years. there have been suspensions+ in/around xpac release / raid tier release, and some TLPs, not including the blatant exploits or dupes that culminated in some susbans.
the holly days are gone - but our future is pretty bright --- Brainiac and crew are pretty damn good