/press behaving differently?

fryfrog · Post by **fryfrog** » Sat Sep 13, 2003 5:21 am

In my scripts, I use /press as a quick... duh, press of a key. /press up and /press down used to do enough to make small adjustments in position or break /follow.

now, /press LETTER works fine (/press backspace brings up map) but /press up or /press down don't result in any movement. Even if i bind a letter like l or p to up/down in eq, and use THAT it doesn't work. am i stupid?

Curious · Post by **Curious** » Sat Sep 13, 2003 8:22 am

/press up and /press down both work for me ... both for small movements, and to cancel /sendkey down up

fryfrog · Post by **fryfrog** » Sat Sep 13, 2003 9:46 am

humm, then i must have done something odd.

fryfrog · Post by **fryfrog** » Sat Sep 13, 2003 9:50 am

I've double checked it, on 2 seperate computers it does not move at ALL, but if i do a /sendkey down down then /press up it DOES stop movement, and /sendkey down up with a /press down also stops movement. BUT it will not make small adjustments. This is using IRC-latest from this morning that has /doability and a couple other things fixed.

fryfrog · Post by **fryfrog** » Sat Sep 13, 2003 10:10 am

Okay, there is definatly something wrong with the version I have.

/sendkey down up makes you go forward, but /sendkey up up doesn't make you stop... neither does /press up. only /press down will make you stop or /senkey down down will make you go backwards.

onetimehero · Post by **onetimehero** » Sat Sep 13, 2003 3:38 pm

in eqlib_main.cpp, comment out the "while" loop that feeds all keypresses into EQ at once.

Code: Select all

	if (!gbUnload) 
	{
		 if	(EQADDR_DIKEYBOARD && (This	== *EQADDR_DIKEYBOARD))
		 {
			if (*pdwInOut >	0) 
			{
				if (gKeyStack) 
				{
					//DebugSpew("DInputDataDetour::KeyStack");
[color=red]	
//					while (gKeyStack !=	NULL &&	(*pdwInOut)	!= 0)
//					{
[/color]
						pNext =	gKeyStack->pNext;
						//DebugSpew("Faking	'%s' as	%s...",gDiKeyID[gKeyStack->KeyId].szName,(gKeyStack->Pressed)?"down":"up");
						rgdod[didAdd].dwOfs	= gDiKeyID[gKeyStack->KeyId].Id;
						rgdod[didAdd].dwData = (gKeyStack->Pressed)?0x80:0;
						rgdod[didAdd].dwSequence = dwSequence;
						rgdod[didAdd].dwTimeStamp =	dwTimeStamp;
						rgdod[didAdd].uAppData = 0;
						(*pdwInOut)--;
						free(gKeyStack);
						gKeyStack =	pNext;
						didAdd++;
[color=red]
//					}
[/color]
					(*pdwInOut)	= didAdd;
					gbInDInput = FALSE;
					return (HRESULT)DI_OK;

See if that works. This will give EQ a chance to register the down/up state between calls to the DirectInput routines.

fryfrog · Post by **fryfrog** » Mon Sep 15, 2003 12:22 am

I should have mentioned that this fixed the problem, thanks. Any idea what changed or why it would have suddenly stopped working?

onetimehero · Post by **onetimehero** » Mon Sep 15, 2003 12:37 am

The detours for the directinput functions were reworked a bit because they originally tried to hook the same functions twice, causing crashes when /unload'ing MQ. In the process of fixing them, I guess i made the keyboard input TOO efficient =).

Glad the fix worked, probably should be CVS'd.

McKorr?

Mckorr · Post by **Mckorr** » Wed Sep 17, 2003 9:30 am

Haven't had the chance to even fix this in my personal copy. I'm on a different work schedule starting this week so I'm about a week behind on all the changes to MQ.

Prolly have time to deal with this tonight, after I diff the latest CVS with my working copy.

After I'm caught up, will fix this in CVS, as well as taking a look at the fixes for /who in LDoN... lots of posts there, have to sort through them and figure out exactly which changes need to be made to fix that.

Valerian · Post by **Valerian** » Wed Sep 17, 2003 9:49 am

Mckorr wrote:After I'm caught up, will fix this in CVS, as well as taking a look at the fixes for /who in LDoN... lots of posts there, have to sort through them and figure out exactly which changes need to be made to fix that.

I think the best fix for LDoN /who would be found here: http://macroquest2.com/phpBB2/viewtopic.php?t=3101

Fixed struct, and possibly even a bit of code change to let you know which instance of the zone you are in... though not sure how useful that would be *shrug*

I'd do it myself, but I'm working 12 hr shifts for a while and have no time for this.. =(

Mckorr · Post by **Mckorr** » Wed Sep 17, 2003 5:27 pm

Used onetimehero's struct. Just need a dungeon group to test it. If it crashes I'll go with the code change instead.

MacroFiend · Post by **MacroFiend** » Sat Sep 20, 2003 1:43 am

Problem w/ removing the keyboard while loop ...

Have noticed up to an 8 second delay at the end of a macro ending (MQ Log saying, "The current macro has ended.") and being able to have any keyboard input register. Mouse motion still remained but I did not attempt any click events.

I haven't tested it enough to say if the keystrokes are lost of queued but when I added the loop back in, keyboard functionality was restored almost immediately.

EqMule · Post by **EqMule** » Sat Sep 20, 2003 1:53 am

the dikeys.h file in the cvs is corrupt, well for vc 6.0 at least... it doesnt handle lf as well as net which can handle both crlf and lf's so anyway... I can check out a cvs, but not yet dared to check one in, Ill have Valerian teach me that... the fix is easy btw... just open it in VC and then save it after you pressed ok on the error it will give u "bla bla detected single line feeds bla bla"

maybe that will fix your problem... maybe its something else... Im not sure actually...

MacroFiend · Post by **MacroFiend** » Sat Sep 20, 2003 2:08 am

Sorry ... should have added ... compiling in VC.NET, running EQ/MQ on a P4 1.6G w/ 512M, nVidia GeForce4 w/ 128M on cable.

Plazmic · Post by **Plazmic** » Sat Sep 20, 2003 2:28 am

/endmacro does a key up event for every key in dikeys.h
"/endmacro keep keys" skips this iirc