Post
by Mckorr » Sat Aug 30, 2003 6:14 pm
Let me clarify the /click problems:
If you are using EQ in either full screen or native windowed mode, the current /click will NOT work. Why? For the current /click to work, EQ must NOT have the mouse in exclusive mode, meaning you have to window EQ and release the mouse using shift+alt+r (or whatever you have it set to.) Now, macros will only run if EQ is in the foreground... and when EQ is in the foreground it has exclusive control of the mouse. Release the mouse, macros stop running, and you can't type commands; /click can't be called, so it won't work.
How are they getting around this to use /click? By using EQW, which allows EQ to have the focus, but the mouse to still be released. That means, if you want to /click you have to use EQW.
I don't consider this a valid solution, just an interim work around. We still need to figure out why /click is not working as previously written and fix it.
This also explains why /click did not work prior to the DirectInput solution. EQ is written in such a way that it grabs, via DirectX, exclusive control of the mouse. Any attempt to write directly to the memory address and cause a click results in a conflict with DirectX, which causes EQ to crash. The detoured solution allowed us to piggyback our own click command onto the DirectInput stream, telling EQ that our mouse had been clicked, even if the button wasn't pressed.
I have yet to determine what change was made to the EQ code that no longer allows us to piggyback our commands using Detours. Until we can do that and fix it, or come up with a way to /click in EQ without using EQWindows, /click should still be considered officially "broken".
MQ2: Think of it as Evolution in action.