Create dynamic toggle-able command prefix

[Woofington]

x-posting this from the old forums:

I want to have a command phrase for almost all of my commands.  However I also want the ability to disable the command phrase necessity for rapid fire commands.  I have a few solutions in mind:

1)  Make two seperate profiles, that are more or less the same but one has a global prefix listening override and the other does not.  Then my default profile has listening disabled with the override in place, and if I want to turn off the control word I say a command which changes profiles and enables listening.  This one is relatively simple but could have some problematic state changes.

2)  Another solution is to use condtional commands such as "[computer;] Engage thrusters"  Then I could say "Computer engage thrusters" or just "Engage thrusters".  I would then rely on an EXP function similar to this: "{EXP: '{CMD}' LIKE '{TXT:controlWord}*'}" to determine if the control word is said, and add on to the function some logic to determine if an override is in place.  This solution is ok, but the problem is every command now (and there could be hundreds) has to have hte command word manually entered, so changing the control word would take a lot of time, which would make it less mobile.

3)  The last solution would be to use suffix/prefix commands.  Have all of my normal commands as suffixes and hten have a single prefix command for the control word.  Then I would have "{EXP: '{PREFIX}' = '{TXT:controlWord}'}" to test if the control word is present.

Obviously solution 3 is the best solution because it allows me to make all of my command and then only edit two locations (the init file which specifiies the txt token controlWord, and the prefix command) to effect what the particular control word of choice would be for all commands. 

However there is a problem, currently there is no way to have a blank control word.  So there is no way to bake in an override because you can never "skip", so to speak, the prefix. 

Am I missing something here, or is this just a current limitation of the system?

[Gary]

Continuing the discussion from the Google group...  What you will want to do is go into the profile options screen (icon at the top that looks like a grey check box).  Select the first option, 'override listening if my spoken command begins with...'.
Type in the prefix there.

This option is a way to override listening when listening is turned off.  It also works when listening is turned on so it's used for situations like you are describing.

If you put, 'computer' in the box and have a command called, 'fire weapon', you can say 'computer, fire weapon' or 'fire weapon' when listening is on.  When listening is off, 'computer, fire weapon' will work, but 'fire weapon' will be ignored.

Hope that helps!

[Woofington]

Thanks that seems like a suitable solution.  Now if I can just get the {STATE_LISTENING} token to actually resolve...

Hey I found a really really weird bug. 

If I have a voice command that will start listening, and the only thing I have in the command is for it to start listening it does exactly what you would expect it to.  When run it starts listening, the status window reports that listening has resumed, and the listening sound effect plays.

However if I have start listening tied under a conditional block, and I run it, it does in fact begin listening however it in no way reports it properly.  The status window does not report listening as resumed, the sound effect doesn't play and even the listening icon does not change (however it does updated once you mouse over it). 

Furthermore for whatever reason in my conditional block, where I test to see if listening is already engaged, it both passes the test, enabling listening, but also fails the test in the else portion thus notifying me that listening was already engaged. 

It appears as though the condition is checked twice, once during the if, and once during the else, whereas it should only check the {STATE_LISTENING} value once and then act accordingly.

[Gary]

You'll probably need to export your profile with the affected command so I can take a look at it.  You can either upload it here or send it to me at support@voiceattack.com.  I toss it on the debugger and see if there's something amiss.

[Woofington]

I've attached the profile.  This was made running the latest beta.  To recreate the issue:

First ensure that listening is disabled.  Then say "Disable safety lock"  You'll notice several weird things:

First it will say "Safetly lock already disabled" which it shouldn't, and it doesn't even make sense given the scenario.  You'll also notice that it accepted the command, for whatever reason, despite not using the override prefix.  Finally you'll notice that it is now in listening mode but it didn't report the change, mousing over the listen button will "refresh it" to the correct state. 

[Woofington]

Just bumping this with  a question.  The update did indeed fix this issue for me, but is there a way to make a certain command be listened for with listening disabled even when it doesn't contain the override phrase?

For instance now I can disable and reenable the safety phrase, which is a prefix of "computer".  But certain things I want to be able to say without having to use the safety phrase even when it is required, such as "hello computer" or "thank you computer" as saying "computer thank you computer" is odd and not natural.

Is there anyway to have certain phrases override whether listening is on or off?

[Pfeil]

Not phrases, but as of the last update(v1.5.8.21), having a "Start VoiceAttack listening" action as the first action in its command will enable it to trigger with listening disabled.

So you could do:

Code: [Select]

Start VoiceAttack listening
Stop VoiceAttack listening
Followed by the actions you need.

[Woofington]

Holy crap thank you, this is perfect!