Unable to replicate keypress

[JohnBee]

I've been troubleshooting macros and discovered what appears like behavioral issue on the key simulation side of things, in-where captured key behaviors are not indicative of their their respective RW key behaviors - for example;

In one particular game, a common action consists of; [CTRL] + s

Whereas Macro Express, captured this as; <TEXT TYPE Action="0" Text="<CTRL>s"/>

However and-upon running the Macro, I discovered the playback does not follow the captured behavior, resulting in anomalies that seem due to timing inconsistencies - my guess being, that of reporting particular keys as remaining in a depressed state rather than being released as in the initial recorded behavior.

Though here again, I am not able to confirm these behaviors with any degree of certainty, as I lack the technical expertise to properly interrogate such things, and so I was wondering if anyone knew of any particular settings that might help capture keyboard behaviors, particularly on the timing side of things, as well as better key press positioning behaviors, with respect to key combination and the likes?

 

 

 

[Cory]

I don't ever use the recorder. I recommend that no one does. Always learn to do it by manually entering the keystrokes. And learn things like when to use the control and when to use control up/down combination (almost never). Things like that.

[JohnBee]

16 minutes ago, Cory said:

I don't ever use the recorder. I recommend that no one does. Always learn to do it by manually entering the keystrokes. And learn things like when to use the control and when to use control up/down combination (almost never). Things like that.

Hi and thanks for the helpful suggestions.

I'd be the first to admit, that I would have likely never considered the recorder to be a potential source of issues in such cases, though I'm happy to take the lower-level route by manually creating my own keystrokes.

With that being said, what is your take on the following keystroke and behavior in game?
<CTRL>s
 

Resulting in; [CTRL] key, being held-down after the fact?

PS. I would add that there are no other macro functions in said test script beyond the above cited keystroke, and that executing the above key combinations in both; macro and real world function, result in completely different behaviors.

[acantor]

Some folks on this forum prefer this method, which separates key down from key up events:

 

Text Type (Simulate Keystrokes): <CTRLD>s<CTRLU>

 

I don't usually find I need to do this, but once in awhile, it's the only approach that works. Normally I do this:

 

Text Type (Simulate Keystrokes): <CONTROL>s

 

In some situations, one might have to slow down output by doing something like this (although I don't think I've ever done it).

 

Text Type (Simulate Keystrokes): <CTRLD>
Delay: 100 milliseconds
Text Type (Simulate Keystrokes): s
Delay: 100 milliseconds
Text Type (Simulate Keystrokes): <CTRLU>

 

[rberq]

28 minutes ago, Cory said:

learn things like when to use the control and when to use control up/down combination (almost never).

 

It is audacious to disagree with Cory, but I recommend almost always to use the control down/up combination.  So you could change your macro script

from <CTRL>s to <CTRLD>s<CTRLU>.  I seem to be the only person who has trouble with one version vs. the other, but maybe you have joined me. 

 

I have had the problem, occasionally, of the CTRL key remaining "stuck" down, but only when a macro has been aborted before its normal end.  You could try adding an extra Text Type of <CTRLU> and see if that helps.  I tested using extra <CTRLU> commands when they are not needed, and it seems to cause no problem. 

[JohnBee]

Hi and thanks for the ongoing suggestions, this is proving to be a most interesting topic, in-that there appears to be timing discrepancies between simulated key presses and their respective target environments.

For example; I've been experimenting with the approaches that have been suggested in this thread, and found the timings associated with simulated key actuations will vary according to their respective process. One example of this, being the latency differences between key actuations in a low(or no) cpu intensive process such as Notepad, and in-contrast with an active game window.

That said, and while this may not prove substantial in non critical timing applications, I've observed that the current measures needed to compensate for such fluctuations can come at the cost of the intended use of the macro itself - if that makes any sense