Author Topic: How do I make "push to stop listening" hotkeys restore previous listening state?  (Read 1259 times)

predi

  • Newbie
  • *
  • Posts: 3
I'm trying to use VA with Speakeasy profile for Arma 3.

I've configured the profile hotkeys (override global hotkeys) so VA stops accepting commands when I use push to talk hotkey for Teamspeak (Caps Lock) and in-game push to speak hotkey (mouse forward button) - I do not want my speech to be interpreted as commands by VA when I'm talking to my teammates.

This however does not work as intended. If VA has been set to don't-listen mode either via the button on VA GUI (headset toggle button) or via a voice command ("speakeasy off" in my case) prior to pushing a configured hotkey, it will auto-enable listening after this hotkey is released! The expected behavior would be to restore previously set listening mode and not to reset this state.

How do I configure VA so:
  • if VA is in don't-listen for commands mode, me using the hotkeys for in-game communication has no effect on VA whatsoever,
  • if it is in listen for commands mode, it stops listening after the hotkey is pushed and resumes listening after the hotkey is released?

Gary

  • Administrator
  • Hero Member
  • *****
  • Posts: 2827
Hi, predi.

Is it possible for you to provide a screen shot of your Hotkeys options tab?  That would give me a better idea of what you have set.

predi

  • Newbie
  • *
  • Posts: 3
Of course.


Gary

  • Administrator
  • Hero Member
  • *****
  • Posts: 2827
Yup - it looks like if you have both set to 'not listen' when one of the methods is released it does not consider that the other means of 'not listening' is still engaged.

I'll add this to the list of items to look into, however, there are several projects in the works for VA at the moment, so there would be no ETA on when this could be addressed, predi.


What you can do is set up Teamspeak's push to talk button to be the same as VA's push to not listen button.  So, for instance, if Teamspeak's push to talk button is F2, you would have VA's push to not listen also be set to F2.  VA's listening would be on the whole time the button is not pressed, though.  Just a thought.

Pfeil

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 4759
  • RTFM
Having VoiceAttack's listening state follow the inverted value of other application's listening states, as Gary proposes, can be done using commands rather than or in addition to the built in option, if you need to trigger that off of more than one hotkey on the same device type (as you can't, for example, have two different mouse buttons assigned to the "Mouse Click Recognition" feature independently)


If you'd rather stick with the behavior you were initially looking for, this command should accomplish that:
Code: [Select]
Begin Text Compare : [{STATE_LISTENING}] Equals '1'
    Stop VoiceAttack listening
    Start Loop While :  Forward Mouse Button Is Pressed
    End Loop
    Start VoiceAttack listening
End Condition
Set it up to trigger off your mouse button, as you did with the hotkey feature before, and if listening is already disabled, the command will simply do nothing (thus keeping listening disabled, even after you release the button); If listening is enabled, it will be disabled while the button is down, and re-enabled when it is released.

predi

  • Newbie
  • *
  • Posts: 3
Not sure what you guys meant, when you suggested to use the "inverted" approach, since that is what I'm already doing:
  • Teamspeak is set to use Caps Lock for push to talk (talk while Caps Lock pressed down),
  • in-game push to talk is set to mouse forward (talk while mouse forward pressed down),
and VoiceAttack is configured as in the screenshot above. We use Teamspeak for pre-game coordination and in-game speak for the actual game, hence two ways of communication.

I did get this to work as desired (at least that is what Log entries now suggest, didn't test in actual game) by following Pfeil's suggestion. I unchecked both checked options in the screenshot above, then added a new command to the profile as in below screenshot.

However, do put this in on your issue tracker as Gary mentioned. As a user (with my software developer hat on), if I explicitly disable something, I expect it to stay disabled until explicitly enabled again, especially for a feature like speech recognition.

Thank you both for the prompt response.