Input needed on /click after 26/27 Aug Patch

Mckorr · Post by **Mckorr** » Wed Aug 27, 2003 3:09 pm

Worked a 24 hour shift yesterday, so of course I've been asleep most of today. I see several messages state /click is not working... exactly WHAT is not working?

To me Click consists of several interlinked functions. So to get started on fixing things I need to know exactly what part of the mouse functions are failing. Is the pointer not being moved at all? Is it moving, but not pressing buttons? Are the button locations all screwed up?

I'll begin work on updating locations.txt shortly... and probably be changing the name to locations.ini, since I should have named it that originally. Can't find the little app Shark wrote to automate the process, so will have to come up with my own or do it by hand, might take a day or so for either method.

If mouse movement has been affected it is either an incorrect memory offset or a struct change. The struct is simple:

Code: Select all

typedef struct _MOUSEINFO {
	DWORD X;
	DWORD Y;
	DWORD SpeedX;
	DWORD SpeedY;
} MOUSEINFO, *PMOUSEINFO;

so I can't see why it would change, but it's worth investigating. Major changes in the UI XML files can also cause movement problems, but those should be corrected with corrections in locations.txt.

The actual click is one of our detoured functions, relying on DirectInput. Not sure why that would be affected at all; if /press and /sendkey are working the /click should work as well.

Please provide me with any information you have on exactly what is not working here so I have a clue as to where to start looking.

spudgun · Post by **spudgun** » Wed Aug 27, 2003 3:26 pm

far as i can tell the mouse is moving but left and right click do not work.

Mckorr · Post by **Mckorr** » Wed Aug 27, 2003 5:45 pm

Thanks. I'll start digging, see what I can find out. Afraid I'm a bit out of touch with the current source code, so might take a bit. All those summer visitors really distract you.

Mckorr · Post by **Mckorr** » Wed Aug 27, 2003 5:58 pm

A struct change here:

Code: Select all

typedef struct _MOUSESPOOF {
   MOUSE_DATA_TYPES   mdType;
   DWORD            dwData;
   struct _MOUSESPOOF   *pNext;
} MOUSESPOOF, *PMOUSESPOOF;

could result in the mouse not clicking properly. Afraid I'm very bad at structs, but will hammer away at it if one of the other devs can't figure it out first.

Will check the mouse offsets first though. Might be as simple as that.

Mckorr · Post by **Mckorr** » Wed Aug 27, 2003 6:38 pm

Looks like the posted offset is correct, though there are a lot of changes inside eqgame.exe. Trying to remember how to hunt struct changes

Mckorr · Post by **Mckorr** » Wed Aug 27, 2003 6:46 pm

Okay, the mouse is moving correctly, within limits for locations.txt. Problem is definately the click itself.

motd2k · Post by **motd2k** » Thu Aug 28, 2003 2:38 am

I was pretty sure there was a structure change when i posted the offset, from memory (havnt got a decompile to hand) one of the addresses in the instructions changed from

Code: Select all

lea edx, dword ptr [ebp-08]

to

Code: Select all

lea edx, dword ptr [ebp-04]

MOTD

Rand · Post by **Rand** » Thu Aug 28, 2003 1:05 pm

This may be related with the problem I have on the euro server. The mouse won t click there.

I added some monitoring in the code and all the detour of the DX fonction work but there is no click event when i add it in the event structure.

javaspot · Post by **javaspot** » Thu Aug 28, 2003 4:22 pm

This is just a wild-assed-guess, but could it be that the dwSequence numbers have to be correct? It seems that EQLib just re-uses the most recent dwSequence number when building the DIDEVICEOBJECTDATA. This would have the effect of the MQ events all having the sequence number of the last real event. Perhaps EQ is discarding any event with a dwSequence<=mostRecentdwSequence.

Rand · Post by **Rand** » Thu Aug 28, 2003 4:31 pm

I trid to increase the dwSequence and to set different timestamp for the click & release mouse event. It didn t work.
the DX function provide the dwSequence , so after the next real event you ll get a dwSequence equal to the one you used for you inserted mouse event.

I also tried what EQmule descibed here :
http://macroquest2.com/phpBB2/viewtopic.php?t=2345
It wasn t better.

But my C++ is far from perfect and I may be wrong.*

Edit : do all of you use DX9 ? maybe they added a different path to process the events when DX9 is installed

Mckorr · Post by **Mckorr** » Fri Aug 29, 2003 11:03 am

Since DirectX is supposed to be backwards compatible, i.e. if you have DX9 it will work fine for a function written for DX8, it doesn't make sense for them to write different fuctions. If EQ only requires DX8 the functions would be written for DX8, and DX9 would still be able to use them.

Perhaps if we recompile using dinput files from the DX9 SDK?

motd2k · Post by **motd2k** » Fri Aug 29, 2003 11:10 am

I've tried that Mckorr... no joy :-/

MOTD

Mckorr · Post by **Mckorr** » Fri Aug 29, 2003 11:34 am

I have to admit I'm kind of boggled here. Lemme think outloud for a moment:

We issue a /click command. This calls our /click function... the guts of which are

Code: Select all

		PMOUSESPOOF pData = (PMOUSESPOOF)malloc(sizeof(MOUSESPOOF)); 
		pData->mdType = mdType; 
		pData->dwData = 0x00; 
		pData->pNext = NULL; 
		if (!gMouseData) { 
			gMouseData = pData; 
		} else { 
			PMOUSESPOOF pTemp = gMouseData; 
			while (pTemp->pNext) { 
				pTemp = pTemp->pNext; 
			} 
			pTemp->pNext = pData

This calls our mouse dinput detour, which grabs control from EQ and tells DInput to left or right click..... okay, that's not precisely what happens, but it's the general idea.

So... we can move the mouse. That's done by directly changing it's location "address". But we can't click. So why are we not calling DInput correctly?

Code: Select all

			   case MD_Button0Click:
				   rgdod[*pdwInOut].dwData = 0x80;
				   rgdod[*pdwInOut].dwOfs = DIMOFS_BUTTON0;
				   gMouseData->mdType = MD_Button0;
				   gMouseData->dwData = 0x00;
				   bRemoveItem = FALSE;
				   bLoop = FALSE;
				   break;

Excerpt from the DInput detours. Two things catch my eye. First, that these functions rely on the _MOUSESPOOF struct. Second, those two hard coded addresses, 0x80 and 0x00. The 0x00 is related to MOUSESPOOF, but what about the 0x80? That is part of a call to the DirectInput function itself.

As motd2k points out, there is a code change:

Code: Select all

lea edx, dword ptr [ebp-08]

to

Code: Select all

lea edx, dword ptr [ebp-04]

Could it be we need to change 0x80 to 0x40?

Okay, shoot me down now =) I'm sure I'm way off base.

Mckorr · Post by **Mckorr** » Fri Aug 29, 2003 11:56 am

Yep, way off base, didn't fix the problem. Back to the drawing board.

Valerian · Post by **Valerian** » Fri Aug 29, 2003 1:23 pm

Mckorr, I have faith in you... find some way to fix Click, and EqMule and I will work on fixing the rest of the code... we're close to being done, and just ironing out a few more CTD bugs here and there.

Input needed on /click after 26/27 Aug Patch

Input needed on /click after 26/27 Aug Patch

eh