G Key Press and Release Detection

[firescue17]

http://privatepaste.com/c5a5634b81

I'm still working on some of the text string discrepancies discussed in the chat room the other day. I managed to isolate a specific Mapped Key which behaves differently depending upon the hotkey used to activate it. I believe this issue is related to using G keys as a hotkey and not an issue related to Key Maps or the EQ client. Due to that, I'm beginning to wonder if this press and release issue is creating the appearance the simulated text string Mapped Keys don't function, when in fact the Mapped Key is fine; rather, the input recognition isn't working.

The Mapped Key in question is "Memspellset: Normal" in "40: Do Master: Shared." This Mapped Key can be activated either 1) Directly through the Backspace key (implemented for troubleshooting purposes); 2) through the use of G17 in "Load: Encounters: Anguish," "Load: Encounters: Luclin," "Load: Encounters: Menu," or "Load: Memspellsets" all four of which are in "20: Control: Load Keymaps."

THEORY:
The Mapped Key "Memspellset: Normal" is used to reset all my character's weapon sets and spell sets to the preferred default. It is available as an option in any of the four, virtualized G Key Menus mentioned above. In practice, as I'm tabbing through menus, I should be able to reset my characters to default in multiple menus. The intent is to only use the G Keys as menu keys. Hardcoded hotkeys such as Backspace are not used. Backspace was added only to troubleshoot and illustrate the problem.

DISCREPANCY:
When activating "Memspellset: Normal" via Backspace with Hold: On, the Mapped Key works as intended:
Press One > Backspace Down > Sends Shift 1
Press One > Backspace Up > Null Placeholder Step
Press Two > Backspace Down > Do "Bandolier: Main Step 1" in "10: Text Strings"
Press Two > Backspace Up > Do "Bandolier: Main Step 2" in "10: Text Strings"
Press Three > Backspace Down > Do "various spell sets" to "various characters"
Press Three > Backspace Up > Null Placeholder Step

The Mapped Key works exactly as it should when activated from Backspace. I want it to work like the above when activated from G17. When activating via G17 with Hold: On, the result is as follows:
Press One > G17 Down > Sends Shift 1
Press One > G17 Up > Null Placeholder Step
Press Two > G17 Down > Nothing happens at all
Press Two > G17 Up > Poptext only - none of the Keystrokes are executed
Press Three > G17 Down > Do "various spell sets" to "various characters"
Press Three > G17 Up > Null Placeholder Step

When used with Hold: On - Activate when Pressed or Released, the G17 key is losing / failing to detect / not sending any of the "New Keystroke Actions" in "Bandolier: Main Step 1 and 2." When Hold: On is off (lol, what?) or default, i.e. not attempting to use G17 Down and Up to execute separate steps, the Mapped Key works as it should, only requiring more button presses.

COMPARISON #1
For comparison purposes, look at "Clicky: Arx Key" in "50: Do Master: DRU." This Mapped Key also used a virtualized G Key to execute two steps, one each on keypress down and keypress up. It works fine 100% of the time. I've never had any problem activating it. The only difference between "Clicky: Arx Key" and "Memspellset: Normal" is the sending of sequential "New Keystroke Actions" in the same step in "Memspellset: Normal."

COMPARISON #2
Also compare "Merc: Healers" in "10: General." This uses a normal key "]" with Hold: On to activate "Merc: Passive" and "Merc: Balanced" in "10: Text Strings." This Mapped Key also works 100% correctly. All of the sequential "New Keystroke Actions" in each step of each Mapped Key get sent, even when using Hold. The only difference here is the use of a normal keyboard key "]" versus the use of a G Key.

CONCLUSION:
In my opinion, there is an issue or conflict with G Keys detecting Press and Release. This issue only applies to G keys and sequential "New Keystroke Actions" in the same step. If this was an ISB profile issue (i.e. I made a target / ATG / Key Map on/off mistake) the Mapped Key would not work at all regardless of what Hotkey was used. If this was an EQ client issue, the Mapped Key would not work regardless of Hold being on or off. If this issue was with the ghetto method of sending sequential "New Keystroke Actions" in the same step, the Mapped Key would not work regardless of Hold being on or off and also would not work when using a normal keyboard key such as "Backspace" or "]."

The Mapped Key should work or, it should not work. There shouldn't be a different result depending upon what key is used to activate the Mapped Key. I have tested all the variables I can think of to illustrate the issue. I am very familiar with using Hold. It's used throughout the profile to get the most bang for the buck out of keypresses.

Hopefully, this illustration is concise enough to help troubleshoot the issue or teach me what I did wrong. I know the profile is a beast to work through.

Thanks!

[lax]

I'm gonna say a) probably not and b) it would be device-specific so you would need to be specific about what your G-keys are on... BUT you can test it definitively.

Use the buttontest.iss script from here http://isboxer.com/forum/viewtopic.php?f=30&t=675 and it will provide output whenever you press a button. If your G-key is programmed in the hardware to also send a keystroke, you'll see both the G17 up/down as well as said keystroke. It's also possible with some devices that ISBoxer interprets extra data that isn't programmed in the hardware, which would be a bug in Inner Space for me to fix for that particular device.

[firescue17]

This is regarding the G15 keyboard.

I ran buttontest. I tested all the G keys and get two lines of spam for each G key press; position=TRUE on keypress down, position=FALSE on keypress up. I could see this happening in game though through some of my Mapped Keys.

I also checked the debugging console. The sequential keystrokes are showing in the ISBoxer Debugging Console; however, they're "not coming out the other end," i.e. showing up in the game chat window.

When observing G17 keypresses in buttontest, if I press and hold the button down for a long time, the debug output is executed exactly as it should be: Press and hold for position=TRUE ... hold the button down ... hold the button down ... release for position=FALSE.

When observing Backspace keypresses with Hold: On in the ISBoxer Debuggin Console, the debug output is separate as it should be: Press and Hold for button: from keystroke@is1: nomodifiers /+B+A+N+D+Space+A+C+T+I+V+A+T+E+Space ... hold the button down ... release and get the debug output button: from keystroke@is1: nomodifiers M+A+I+N+Enter.

When observing G17 keypresses with Hold: On in the ISBoxer Debugging Console, the debug output is only from the keypress up: Press and hold - nothing happens ... hold the button down ... release and get both debug output upon release: button: from keystroke@is1: nomodifiers /+B+A+N+D+Space+A+C+T+I+V+A+T+E+Space and also button: from keystroke@is1: nomodifiers M+A+I+N+Enter. Those should be separate, should they not?

[firescue17]

Additional testing: I went through every Mapped Key in the profile and watched the activity in the ISBoxer Debugging Console. Every single one mapped to a normal keyboard key does the appropriate output upon keypress Down and keypress Up.

None of the Mapped Keys mapped to a G key executed any output upon keypress down. Every single one output both the keypress down step as well as the keypress up step upon release of the key.

[firescue17]

<Insert bad word here>.

So, I had an epiphany after seeing written results of my testing. I now believe the issue is due to virtualizing the G15 hotkeys. I jumped back up a level in the hierarchy to "00: Virtual G15 Hotkeys" and set every one of the base hotkeys to Hold Off: Execute on Pressed or Released. I am now seeing the expected output in the Debugger; however a good portion of the Mapped Keys blew up due to executing upon Pressed and Released two levels deep, i.e. it's trying to fire 4 steps upon a single keypress. I now need to rework the entire profile (once again) and will follow up with the results; however, this "makes sense" and I expect it to solve a whole bunch of the weirdness I've been chatting about in the last few months.

In order to use Pressed and Released with virtualized keys in this manner, I anticipate every single-step Mapped Key to require an ending empty step. This could possibly use a footnote of some sort in the Like A Pro documentation. The base hotkeys at first glace appear to be the least complicated part of virtualizing a profile. Once they're set, you never ever go back to them.

[lax]

If your G-Key hotkeys are just doing a Do Mapped Key Action (e.g. as an Alternate Hotkey), they should be configured WITH HOLD ON. This will push both the Press and the Release independently to the Mapped Key being executed, so that the Mapped Key being executed will retain its original behavior for the press/release events. (And, by the way, if you use the Mapped Key Wizard or right click and select "Create Alternate Hotkey", it should be set to Hold for you automatically for this reason.) It sounds like your alternates (G-key Mapped Keys) were set to the original default, "Released".

This is a better footnote than using pressed/released with empty steps.

[firescue17]

Won't single step Do Mapped Keys rollover on release and attempt to do them self again - step 1 on keypress down and step 1 immediately again on keypress up?

[lax]

Won't single step Do Mapped Keys rollover on release and attempt to do them self again - step 1 on keypress down and step 1 immediately again on keypress up?

No, because the original behavior of the Mapped Key being done is kept by the Hold option:

• The Mapped Key being done will get a Press, and a Release, and is configured to activate either on Press or Release, and therefore will treat it the same as if the Hotkey was pressed directly.
• If the Mapped Key being done has the Hold option, it gets the Press, and Release, and will also treat it as if the Hotkey was pressed directly (press on press, release on release).

[firescue17]

I don't presume to understand how Hold: On works with single step keys, but thank you for the help. I reworked the entire profile from the base Hotkeys down and it fixed everything I expected it to. This addressed a slew of step sync weirdness I was experiencing while operating under the impression the steps were executing on keypress down and keypress up.

This fix also improved sending sequential keystrokes on the same keystep. I can now chain two steps full of "New Keystroke Actions." This allows for a total of 30 characters, 15 each on two steps to be sent per keypress. Provided one stays within the 30 character limit and properly opens chat on keypress down and closes chat on keypress up all the issues I was experiencing with unterminated text strings have been alleviated as well.

This is a HUGE improvement! This fix doesn't address the "New Key String Action" clipboard issue with EQ; however, extra keypresses aside, the 30 character limit appears to be more than sufficient for all purposes I've envisioned (so far).

As always, ISB continues to amaze me.