Approaching /click from a DirectX angle

A forum for feature requests/discussions and user submitted patches that improve MQ2

Moderator: MacroQuest Developers

Mckorr
Developer
Developer
Posts: 2326
Joined: Fri Oct 18, 2002 1:16 pm
Location: Texas

Approaching /click from a DirectX angle

Post by Mckorr » Thu Mar 27, 2003 3:50 pm

Look in the DX SDK, /Samples/C++/DirectInput/Mouse. This code creates a small program that reads mouse locations and button clicks...

Since this code tells us what we want to know, couldn't we cut and paste it together to have MQ initialize the mouse in background/nonexclusive mode, and then read the mouse position and button clicks, feeding them back into EQ?

Or am I way off base?

User avatar
dont_know_at_all
Developer
Developer
Posts: 5450
Joined: Sun Dec 01, 2002 4:15 am
Location: Florida, USA
Contact:

Post by dont_know_at_all » Thu Mar 27, 2003 7:24 pm

Well, yes. That's what we want to do. We even know the mouse coordinates from inside eqgame.exe. Someone posted the offset earlier.

The problem is that there is no DX way of introducing a click. The mouse is an input only device.

I think we have to go above DX and use a WM_LBUTTONDOWN/WM_LBUTTONUP combination.

eqjoe
a grimling bloodguard
a grimling bloodguard
Posts: 984
Joined: Sat Sep 28, 2002 12:26 pm

Post by eqjoe » Thu Mar 27, 2003 10:17 pm

If you have ever seen Xylobot work, one must calibrate the "Xylobot curser" with the "game curser". We would have to read the mouse coordinates from EQ memory to avoid something similar.

BUT , as you may have noticed, we still have "fast plat" kiddies looking for a way to do AFK macroing. It would be very tough, if not impossible to use Xylobot to AFK macro tradeskills for a profit. So those "plat farmers" are still looking for a way to get something for nothing. If we put /click back in, you can be sure that SoE will be out to break MQ again.

/click is not worth it. I think our time is better spent working on other things.

User avatar
dont_know_at_all
Developer
Developer
Posts: 5450
Joined: Sun Dec 01, 2002 4:15 am
Location: Florida, USA
Contact:

Post by dont_know_at_all » Thu Mar 27, 2003 11:33 pm

You'll notice that I have not implemented my own suggestion. I agree about /click.

Does anyone here have a contact in development in SoE or VI?

I remember a post about that before, but I can't find it.

Mckorr
Developer
Developer
Posts: 2326
Joined: Fri Oct 18, 2002 1:16 pm
Location: Texas

Post by Mckorr » Fri Mar 28, 2003 8:39 am

So keep /click private, i.e. developer only. Myself, I never found any "fast plat" macros... or any of the actual profit making tradeskill formulas. Yes, I know some of you knew them, but I never did... nor ever worried about them or looked for them.

What I want /click for: paladin Freeport faction fix quest in Erudin; auto-looting of a few things I use for raising my smithing skills (all nodrop stuff); annoying repetitive trade skill combines... I'm getting old, Army takes its toll, and I'm gettin' arthritis.

You could always put the /click function external to the main MQ source, a seperate DLL or something, and release that code seperately to trusted people.

User avatar
driftinsupra
Official loudmouth
Official loudmouth
Posts: 212
Joined: Tue Jan 28, 2003 9:25 pm

Post by driftinsupra » Fri Mar 28, 2003 10:02 am

I dont hink fixing /click will have as big of an effect as you think. As you can probably see from the ammount of posters and whatnot, by not releasing the binaries the amount of Macroquest users had dropped, to almost nil. Adding /click back in wont affect the game as much as it did and plus I think SoL has destroyed just about every easy way to make plat.

Mckorr
Developer
Developer
Posts: 2326
Joined: Fri Oct 18, 2002 1:16 pm
Location: Texas

Post by Mckorr » Fri Mar 28, 2003 12:18 pm

I doubt fixing /click will make SOE try any harder to kill MQ. They already want it dead, so they'll keep working on their memory checker and changing it with every patch, breaking MQ more and more till people give up in disgust.

Understand, it is enough that they finally took enough notice that they did something about it. They won't stop, even if only a handful of us using MQ remain. Also consider that anything learned by them here can be applied to later games. Especially EQ2, where it is promised that trade skills will actually mean something and can be truly used to support yourself.

Think about it. Customer support (GM's, not Guides) began going downhill when they got EQ2 to a serious point in development. Those GM's and programmers went someplace, either SWG or EQ2. EQ right now is more of a testbed for them. Read a few articles, even LoY looks like an attempt to test implentation of advanced NPC scripting and NPC zoning capabilities, things promised for SWG and EQ2 (which apparently use the same game engine, from looking at the various promised features.)

So, as long as there are lessons to be learned from antihacking or antimacroing attempts in EQ they will continue to implement them. Whether or not /click is fixed.

lol Okay, off my soap box now. I can get by without /click, but I'd certainly like to see it restored. It was very useful for me, and I don't mean as a plat making tool (someday one of you will tell me how you actually managed to make plat with trade skills, and I'll finally be able to afford that horse.)

User avatar
L124RD
Site Admin
Site Admin
Posts: 1343
Joined: Fri Jun 14, 2002 12:15 am
Location: Cyberspace
Contact:

Post by L124RD » Fri Mar 28, 2003 2:40 pm

Salutations,
I doubt fixing /click will make SOE try any harder to kill MQ. They already want it dead, so they'll keep working on their memory checker and changing it with every patch, breaking MQ more and more till people give up in disgust.
SEQ had this problem, then they just started breaking it when they came up with a new idea. We are doing this for fun. I got SB yesterday, made it to level 8, and am already looking into ways to make MQ work for it (though we can already see npcs in the radar in a fantasy game?)
Understand, it is enough that they finally took enough notice that they did something about it. They won't stop, even if only a handful of us using MQ remain. Also consider that anything learned by them here can be applied to later games. Especially EQ2, where it is promised that trade skills will actually mean something and can be truly used to support yourself.
Tradeskills will never mean anything to me until I can level without killing a single thing. That is when I will make my pacifist monk and rule the world.
Think about it. Customer support (GM's, not Guides) began going downhill when they got EQ2 to a serious point in development. Those GM's and programmers went someplace, either SWG or EQ2. EQ right now is more of a testbed for them. Read a few articles, even LoY looks like an attempt to test implentation of advanced NPC scripting and NPC zoning capabilities, things promised for SWG and EQ2 (which apparently use the same game engine, from looking at the various promised features.)
You know, after htinking about it, if a new projecct came up in your workplace that was more interesting then your current one and you already had all the skills for it, wouldn't you switch too?
So, as long as there are lessons to be learned from antihacking or antimacroing attempts in EQ they will continue to implement them. Whether or not /click is fixed.
As long as they continue to learn by breaking it, We'll continue to learn by breaking the break (?). If you look over to f-h (where I know none of you go since none of you offset hack :roll: ) you will notice that they have come up with even another method to get around the memcheck then we did, a rather interesting feat imho.
ol Okay, off my soap box now. I can get by without /click, but I'd certainly like to see it restored. It was very useful for me, and I don't mean as a plat making tool (someday one of you will tell me how you actually managed to make plat with trade skills, and I'll finally be able to afford that horse.)
wait, didn't you say that they'd learn from what we did if we make /click useable? we scanned all the tradeskills, found which ones made a profit., made a macro within 24 hours, exploited the hell out of it, shared it with the world, got it nerfed.

JohnDoe
decaying skeleton
decaying skeleton
Posts: 4
Joined: Fri Mar 28, 2003 2:59 pm

Post by JohnDoe » Fri Mar 28, 2003 3:08 pm

About a year or so ago back before I discovered detours I wrote a wrapper DLL for direct input for use in a beta game I was testing. It was trivial to inject a mouse click or any other key press for that matter. Where the cursor is, is another matter.

User avatar
dont_know_at_all
Developer
Developer
Posts: 5450
Joined: Sun Dec 01, 2002 4:15 am
Location: Florida, USA
Contact:

Post by dont_know_at_all » Fri Mar 28, 2003 5:29 pm

JohnDoe wrote:About a year or so ago back before I discovered detours I wrote a wrapper DLL for direct input for use in a beta game I was testing. It was trivial to inject a mouse click or any other key press for that matter. Where the cursor is, is another matter.
Care to post the code?

eq_freak
a ghoul
a ghoul
Posts: 105
Joined: Mon Jun 24, 2002 7:17 am

Post by eq_freak » Sun Mar 30, 2003 8:38 am

I think what you need to do is hook the GetDeviceState function(just like MQ currently does for the keyboard). For simplicity lets assume EQ uses immediate mouse data, then it will most likely have some code like in the DX sample:

Code: Select all

HRESULT ReadImmediateData( HWND hDlg )
{
    HRESULT       hr;
    TCHAR         strNewText[128] = TEXT("");   // Output string
    DIMOUSESTATE2 dims2;      // DirectInput mouse state structure

    if( NULL == g_pMouse ) 
        return S_OK;
    
    // Get the input's device state, and put the state in dims
    ZeroMemory( &dims2, sizeof(dims2) );
    hr = g_pMouse->GetDeviceState( sizeof(DIMOUSESTATE2), &dims2 );
Ie, the function creates a DirectInput mouse state structure and passes the address of said structure to the GetDeviceState function, then once GetDeviceState returns, the structure is filled with the current data on the mouse and these are used in the application.

If you hook that GetDeviceState call you can fill the mousestate structure with whatever coords/mouseclicks you want.

icon
Official loudmouth
Official loudmouth
Posts: 158
Joined: Fri Jun 14, 2002 2:59 pm
Location: ...
Contact:

Post by icon » Mon Mar 31, 2003 12:48 am

L124RD wrote:
...If you look over to f-h (where I know none of you go since none of you offset hack :roll: )
f-h? what's that? You mean that evil haxoring place? *gasp* Of course none of us would ever go there in a million years! How can you even suggest the possibility? I'm ashamed of you for mentioning such an evil place!

- Icon
In memory of [b][color=darkblue]MasTerKeyZ[/b][/color].

User avatar
L124RD
Site Admin
Site Admin
Posts: 1343
Joined: Fri Jun 14, 2002 12:15 am
Location: Cyberspace
Contact:

Post by L124RD » Mon Mar 31, 2003 9:23 am

Salutations,
I know I know, I figured that since I at least have my toe in the pirranha water I'd tell you the things pertaining to this forum... but thats offtopic...

eqfreak: so we have a getdevicestate, so usually that means there is a setdevicestate? i'm guessing not or it would be to easy...

Jay
a lesser mummy
a lesser mummy
Posts: 59
Joined: Tue Jan 28, 2003 11:37 am

Post by Jay » Mon Mar 31, 2003 10:28 pm

Nope, no set device state in DirectX. Is there any way to set the hardware address (as in the memory addess in windows) for the mouse buttons?

JohnDoe
decaying skeleton
decaying skeleton
Posts: 4
Joined: Fri Mar 28, 2003 2:59 pm

Post by JohnDoe » Tue Apr 08, 2003 12:58 pm

Looks like eq_freak is on the right track to me.