[Feature request] Variables

[Masserio]

Hello!

It's been suggested by Suskeyhose in here before, but he didn't get a reply on neither of his two posts, so I'm going to try this again!

Variables would be a great addition to the program, adding tons of new possibilities.
Now there are several different ways to solve how they can be implemented, and a wide range of complexibility/simplicity.
I won't go into many of these, but from how Voice Attack is set up allready I have one suggestion I'd like to pitch to you:

You could make the variables seperate from commands, so in a profile you would have a list of commands, and a list of variables (these can be on different tabs in the edit profile page for example).
When making a new variable, you declare the name, default value, and potentially type (boolean, integer, string).
Then, to change a variable trough a command, you make a new option under "Other": Change variable. Here a new input box or dropdown menu appears so you can reassign the value.

To make use of the variables, you make it another option when adding an action in a command.
Similar to the "Command type" and "Repeating" option in each command, every action in the commands can have a variables option.

With this, a command can be configured to only perform certain actions under special conditions. For example, only execute this action if the variable FollowTarget is false.
In games, this can be used to not accidentally toggling something on/off, since most games have toggled options (for example auto-walk, HUD options, and so on).
Now you have to remember yourself if you allready turned something on, but with variables you can have seperate commands that alter variables.

You could also nest action under variable checks, so you make one sequence of actions for when a variable is true, and one sequence for when it's false.
This shortens the amount of work per action, but makes it a bit harder to have a good overview of what is executed under what conditions.

I tried to keep this as short as possible, but if you'd like I could go over several other solutions for implementing this. I could also probably write some pseudo code if you are interested.

I hope you'll consider this, as it should be a fairly easy thing to implement given that you figure out how you want users to be able to handle it.

Hope to hear back from you on this! You've allready done a really good job with Voice Attack, and I would love to see it taken to new levels of what this amazing program can do!

Sincerely,
Masserio

[Gary]

So, something that would just store/toggle a value and then have an action that executes based on that value might not be too off base. I had to think on this a bit... Sorry for the late reply!

Gary

[Greg LeBreck]

I would like to second this. But take it a step further.

I work extensivly with voice activation for home automation systems. We have been successful in implementing Variable based commands.

For example: 

Voice command is: Move * ... The star could be "up", "down" "left" or anything you wanted. It takes the last word you say (which is the *) and places it into a variable, which can then be passed into another command. We have also done it where the * is inbetween words like .. "on * goto".. this takes anything you say in between the words and places it into a variable. 

This whole thing would also need a basic "if then" sytem in the commands. This way I could say "Go Up", or "go daown". Up and Down would be placed into the variable and sent to a command. That command could have a if statement that did different things based on what was passed.

Please dont get me wrong. VA is awesome and is more than worth the 8 dollars it costs. Just some thoughts on expansion.

Thanks

[Carlos Bricio]

We're slowly crawling into the realm of grammar (which I'd be all over, but gets quite complex).

[Greg LeBreck]

Agree it would be complex. But I look at it like its there for the power users.

As is I have already developed a program which is called from voice attack and does a "Kill Counter", and a few other things that are in the works. Would be great if I could send parameters based on dynamic voice input.

[Masserio]

Exactly! Just something to toggle a value, and that commands can use these values to perform different actions, would be a huge improvement in userability.
Let me know if you want me to toss out a few other ideas on how this can be implemented, in case you're not sure how you want it to fit with the rest of the program yet :)

Greg LeBreck:
The wildcard method you described (Move Up/Down), sounds like it's just to shorten the amount of commands you have in your profile. Note that this also leads to more complex and possibly messy individual commands (there would be a lot of if else statements in there).
While this is good for having a neat looking profile, you could easily fix your example by having seperate commands for this(with a larger amount of commands naturally, making it slightly more messy). With variables implemented, you then just need to set the value to remember up or down, so it does not perform actions of the command is called twice.
I'm sorry if I misunderstood your reply.

Masserio

[Hammerhai]

Yes, a type of conditional execution would be welcome:

In Star Citizen for instance this would come in useful to execute different actions depending on the command given before. Right now after boosting power to guns or whatever is difficult to recenter on the power distribution grid, necessitating using special commands depending on where your power was allocated. Still, it is more of a "nice to have" kind of thing, as it basically needs a kind of command language to use properly.

[Chris Burgan]

any sort of basic variable implementation system could completely negate the need for things like this. https://github.com/dsmith86/StarCitizen-VoiceAttack-AutoHotkey#ahk anything that can be rigged in VA to achieve "states" that can be used to make more complex things on the back end of the commands and make them simpler would be awesome. I LOVE the ; to randomize the resoponses thank you for pushing updates so fast and keep em coming. already well worth over $8.

[Greg LeBreck]

I actually use AutoIT and do the same thing for the flight modes. Also a kill counter. Samething just use a different thing to write it

On Tue, Jun 24, 2014 at 3:24 PM, Chris Burgan <chris...@gmail.com> wrote:

any sort of basic variable implementation system could completely negate the need for things like this. https://github.com/dsmith86/StarCitizen-VoiceAttack-AutoHotkey#ahk anything that can be rigged in VA to achieve "states" that can be used to make more complex things on the back end of the commands and make them simpler would be awesome. I LOVE the ; to randomize the resoponses thank you for pushing updates so fast and keep em coming. already well worth over $8.

--

---
You received this message because you are subscribed to a topic in the Google Groups "VoiceAttack" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/voiceattack/cvNpbUuByZY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to voiceattack...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gary]

Going to throw this out there and let you guys roll it around a little.  I think I'm down for the state thing.  What I've jotted down in my big, yellow pad looks like this :

1)  A set state command (from, 'other stuff' screen)

     This will allow you to set any one of, say, 128 (arbitrary) states.  They will be called, 'State 1', 'State 2' unless it becomes necessary to actually name them.

     The states values are always numeric with range of  int16/int32 whatever... doesn't matter for this, i'm sure.

     

     The state value can be set to one of four things : hard value, increment (if clear (null) increments from zero (that would be 1)), decrement (if clear (null) decrements from zeor (that would be -1)) and clear (null... no value... on the

     fence about this).

2)  An 'Execute Command on Condition' command action. 

    This will have a subcommand to select (just like on the, 'execute another command' screen).

    

    The condition will simply be, when selected StateX equals, does not equal, is less than, is greater than, is less than or equal to, is greater than or equal to, is cleared (null), is not cleared (not null)

    then execute command.

    After the command is executed or not executed, we can then decide if we want to bail out of the host command.

   Probably two radio boxes with options like :

   

   Condition met :

       Continue

       Stop

    Condition not met :

        Continue

        Stop

   This is to somehow not end up with if then else else if else if else if else if else if in a single command.  You can always add more 'Execute Command on Condition' command actions in the host command.

I invite you to see if this model fits what you have in mind, or, if what you have in mind can somehow be rearranged to fit this model.  I think this is about as simple as I can make it.  It has to be as simple as possible, since it is for a broad audience, and (most importantly), I still have to support it.  Although it doesn't seem too terrible to implement, the devil is always in the details :)

Gary (going to bed now... good night, folks!)

To unsubscribe from this group and all its topics, send an email to voiceattack+unsubscribe@googlegroups.com.

[Masserio]

Sounds good to me. As long as the states can be set/manipulated/checked troughout the profile.
So that you can have different commands for a toggle button (e.g. open and close a door), and you can use one value to check if it is toggled. This way, if you say "Open door" twice, it won't close it the second time. Also, it won't open the door if you say "Close door" while allready closed.

As stated several times, this could quickly become very complex, but the way you had in mind makes it simple and easy to use for the entire user-base, and I think it will go good with the program :)

Keep up the exellent work! (I totally agree that VA is allready worth more than the $8 it costs, you should make a donate button for those of us who value this a little extra ;P)

Masserio

To unsubscribe from this group and all its topics, send an email to voiceattack...@googlegroups.com.

[Trevor Woodcook]

Ohhh a donate button. I'd be up for that!

 

Or if you really wanted you could just buy more copies of VA and gift them to your gamer buddies. :)

--

---
You received this message because you are subscribed to the Google Groups "VoiceAttack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to voiceattack...@googlegroups.com.

[Greg LeBreck]

I think it looks pretty good. Should be fairly simple for most people to understand.

[Jerry Ozbun]

I would also totally be down for as Donate button!

The feature sounds great too :)

You received this message because you are subscribed to the Google Groups "VoiceAttack" group.

To unsubscribe from this group and stop receiving emails from it, send an email to voiceattack...@googlegroups.com.

[Masserio]

Allready bought one for a friend :) But I think many would donate extra to show their apreciation!

[Jerry Ozbun]

Gary

I know you addressed the "how" of buying VA fo9r a friend, but I forgot what the answer actually was. Should we just use their email address? Can you set up an option to "Buy as a gift" that will allow you to tie a copy of VA to a different email account?

Thanks - Jerry

--

[Suskeyhose]

I'd like to thank you for ressurecting this, I just finished moving halfway across the US, and was just coming back to try and post this again, but you've done a better job than i could have. Thanks!

              -Suskeyhose

[Hammerhai]

What you outline would do the job, I think. Seems to me to be fairly similar to developing logic latches on the thrustmaster f 22 way back in the old day.

For some reason I kept thinking of the case construct in Pascal as a model too. Or am I way off base there?

We already have a type of conditional execution with prefix and suffix, and for MechWarrior Online I already ran into a situation where I could have used more than 2 "groups" of affixes, for want of a better word. In other words a type of chaining of affixes. In case you are wondering, I use VA to drive Text Comms with other PUGs in Game. It is not faster, but does add to the immersion. The only problem is the delay between full phrases, which groupings of commands do not seem to suffer from.

(Just as an aside)

either way, conditional execution would put VA absolutely heads and shoulders above other VR software, so it is great to hear you are interested.

[Gary]

For right now, I don't have a case statement for this feature.  I'm trying to cut this thing out to be as simple as possible, since I have to support it and be able to explain it (somehow... lol).

Here's where I am on this, for all that are following along...  forget whatever I said earlier (for the most part).  I think I have simplified this a little bit more in some regards (yeah... there are more words, but the concept is simpler, I think). 

I have finished the user interface portion for adding and updating the values for what I am now calling, 'Conditions'.  To set a condition value, you just select, 'Set a Condition Value' from the other stuff screen (see attached... verbiage will change).

For now, there are up to 256 (arbitrary number) condition values you can set.  Condition values are integers with an Int16 range (-32k to 32k).

There are four ways to set a Condition value:

Explicitly (Condition Value = 200)

Randomly (Condition value = random number between low number and high number)

Incremented (Condition Value = Condition Value + 1)

Decremented (Condition Value = Condition Value - 1)  

To help me test out this stuff, I added another TTS token {CONDITION:X}, where X is the condition number (1 to 256).  This just reads the set value.  

I don't have a plan to, 'name' the conditions, other than, 'Condition 1', 'Condition 2'.... 'Condition 256'.

The next step will be to include Condition Start and Condition End actions.  Depending on where they are placed will control whether or not the following actions will be executed.  I'm thinking that you will not not be able to save your command if the number of Condition Starts does not equal the number of Condition Ends.  This is probably the simplest thing I can do so that we can do so we can nest our conditions.

Stuff

More stuff

Condion Start

   Do someting

   Do another thing

   Condition Start 

       Something

       Something Else

   Condition End

   Do whatever

   Beep

   Blink

Condition End

Conditions will be, 'scoped' to the command they are in (conditions should not be affected by sub commands (hope)).  

To start, composite commands will NEED to have corresponding start and end actions in order to be saved.  This could get very ugly otherwise.

Condition checks will be like so :

If Condition X equals, does not equal, is less than, is less than or equal to, is greater than, is greater than or equal to - SOME VALUE.  This value is a value you choose... I am thinking about making this soft-set by allowing another condition to be compared... that may be going too far... we'll see.

I indicated earlier that another check could be 'set / not set'... this may not even be necessary, since incremented / decremented values initialize at zero (your first value will always be 1 or -1).

So, one of the main reasons for the push on this feature (outside of all of the requests) is that it resolves the rotating/random exec command feature that I had on deck.  The random exec command could be handled like this (as well as handle kind of a weighted random response):

Command is, 'Open the pod bay doors, HAL'....

Set Condition Value 1 = Random (1 to 5)                            

Condition Start -> If Condition Value 1 is greater than 2    (note that its greater than 2... could be 3, 4, or 5... 60% of responses)

    Say, 'I'm sorry, Dave.  I'm afraid I can't do that'

Condition End

Condition Start -> If Condition Value 1 is less than or equal to 2  (1 or 2... 40% of responses)

   Say, 'What you talkin' 'bout, Willis?'

Condition End

The rotating exec command feature could be handled like this :

Condition Start ->  If Condition 1 Value is greater than 3

    Set Condition Value = 0

End Condition

Set Condition Value 1 = Increment Value

Condition Start -> If Condition Value 1 = 0

   DOTS

End Condition

Condition Start -> If Condition Value 1 = 1

   More DOTS

End Condition

Condition Start -> If Condition Value 1 = 2

   Stop DOTS

   Do something other than dots

End Condition

Condition Start -> If Condition Value 1 = 3

   More direct damage here

End Condition

Phase 3 will include being able to call out to a user-defined dll, passing the profile/command name as well as condition information & maybe a return value (condition).  Also toying with the ability to pass in a delegate to control some aspects of VoiceAttack.  All on the yellow pad.

Ok, wow... I've typed up a bunch.  I know this looks complicated, but I think once its honed down into the interface, you'll have no problem (I hope).  Have a great evening!

Gary

[Masserio]

This looks great!
Just to clarify; conditions are global and can be interacted with from other commands?
E.g. the commands "Open door" and "Close door" both use Condition42 as a reference to weather the door is allready open or not.

Looks simplified enough and still adds a great deal of functionality :)
I'm a programmer and are familiar with if-else statements though, but it shouldn't be too hard for "laymans" to wrap their head around it I hope.

[Hammerhai]

I know I can work with what you propose. It just depends on how programming literate an avg user is nowadays. I know I cannot make head or tail of modern compilers, being used to SPECTRUM BASIC and such. Yes, I am bald and grey in the beard. And I program, scripting is newfangled, TYVM.

Between an extended suffix -prefix system and this, it is pretty much what I want from a program.

And, as before, best of luck with the CIG thing. Best advice from an old coot: License your property, don't sell the IP outright.

[Gary]

Yes.  The conditions will be at the application level (global) and can be checked and set from any command and even between profiles.

Gary

[Gary]

I am finishing up testing on Conditions (integer variables) and Condition Blocks ('if' statements).  Attached are the three new screens that I have so far, plus two command examples (one is a rotating execution example (1, 2, 3, reset, 1, 2, 3, reset, etc), the other is for random execution).

What I ended up doing is allowing you to name your conditions (wasn't going to do that initially). The conditions are at the application level, so, make sure you name them properly (uniquely) for whatever purpose you have for them.  They are not case-sensitive, but, if you type your condition name wrong when trying to access the value, you will get nothing back.  In this iteration, I added the ability to increment/decrement by x (instead of 1) as well as all you to set a condition value to the same value as another condition.

There are no switch/case statements and no, 'else if' statements.  Just simple blocks that can be nested.  I am probably not going to do anything more advanced in that regard, since not everybody is a programmer and I think this is pushing it kind of far in regards to usability (however, if you *are* a programmer, you'll probably be able to figure out what you need with what's here... at least for now, it seems flexible).  I will probably be adding the option to stop the command if a condition is or is not met via the End Condition block statement, tho (I think that would be understood by anybody).

In the rotating execution example, you'll notice that the condition increments by one, then the condition is checked.  If the value is 1, then one sound is played. If the value is 2, another sound.  If 3 or more, we play yet another sound and then reset the index.  Notice that the 3rd condition check (for the value 3) is against another condition (variable) that I had set to 3 (just for example, pretend the condition value was set to 3 in another command).

Also, if you've got a keen eye, you'll notice that in the check for condition one, there's a path token in there.  There are 3 new tokens... {VA_DIR}, {VA_SOUNDS} and {VA_APPS}.  Those indicate the VoiceAttack install directory, the new Sounds subdirectory and new Apps subdirectory.  There are some folks out there that are creating sound packs and delivering VoiceAttack profiles with those sounds.  I figured this might be helpful if they want to have a common location without having to redo entire profiles (more on that later).  The apps dir will be where any new plugins will need to be located (also, more on that later).

In the random execution example, you'll notice that it's basically the same as the previous example.  The only difference here is that the condition value is set to a random number instead of a number that increments.  Also, there is no action to reset the value.

I was going to have separate rotating/random command execution actions that would have had set (limited) number of items.  Going this route, although not as easy to set up, will allow you to have any number of items to include, but would allow for pretty much any kind of sequence (not just other commands).

Going to look at having another set of variables which will be text values (strings) that can be used with TTS (or whatever else).  This will work just like the numeric values (but you wont be able to use them as conditions (at least for now)).

In phase 3, I'm going to look at defining somewhat of a plugin interface... more like a, 'helper'.  There will be a separate action that can be used to call an external dll (that will need to be in the, 'apps' subdirectory).  There will be a defined interface for the dll (hoping to keep the function count to just one).  You will be able to specify as many conditions to pass in... probably separated via semicolon :  'condition1;conditoin2;condition99'.  These values will be passed in as a dictionary of string/integer that can be set to whatever you want to set them to be.  The action will allow for VoiceAttack to wait for the return of this function... if we wait for the return of the function, VoiceAttack will update its condition list if it is modified (conditions can be updated, added or removed) in the dll.  Since we have a named plugin in a known place, VoiceAttack will create another variable space to share with that plugin so that the plugin can retain state (without having to come up with a scheme to keep alive).  That way the function can be called, the dll can process whatever, set its state values and terminate.  It can then reference the state values on subsequent calls.  Again, this is a private space so that if more than one plugin is in use, they can operate without stepping on each other.  So, with all that, a dll can be called, values can be set, stuff can happen in the dll and then on return, conditions can be checked and then VoiceAttack can be set up to react however you want it to... that's the plan, anyway.  It's all down on yellow paper :)

Hope you are having a great 4th!

Gary

[Masserio]

This looks great, I can't wait to test it out!

[Greg LeBreck]

Yes looks totally perfect. I think it is a great addition.

On Jul 5, 2014 5:52 AM, "Masserio" <mass...@gmail.com> wrote:

This looks great, I can't wait to test it out!

--

---
You received this message because you are subscribed to a topic in the Google Groups "VoiceAttack" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/voiceattack/cvNpbUuByZY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to voiceattack...@googlegroups.com.

[Travis Young]

A set location for sounds is an excellent feature! I'll definitely be able to make use of that. In fact one of the main reasons I HAVEN'T released a sample VA profile with my Voice Pack is that the paths would be a pain to modify.

I really like the idea of the basic variable/script support you've included, though I wish the 'play sound' function had an easier way to randomise. Like the TTS does.

[Gary]

I actually added the sounds directory as a direct result of your sound pack...  whenever you emailed me about it, I figured that would be the next step :)

At some point I'm going to make the path configurable as well (does not have to be in the VoiceAttack directory).

I would put your compilation in a folder called VRComps\WhateverTheCompilationNameIs, since I'm sure you'll probably be making more (probably telling you something you already know)  :)

Play a Sound actions would look something like this :

{VA_SOUNDS}\VRComps\CompilationName\003_heatsink.wav

The only problem with this is that it will be delivered only in beta releases for a little while (at least until plugins go full release)  :(

Gary

[Travis Young]

ahh, that's great!

We've locked in our voice artist to do another session this weekend. Should bump the voice pack to something like 600+ samples for people to choose from and now that I know we can randomise those responses I'll be more comfortable with leaving in multiple variants of each sound too.

You've created a monster! of the best kind!

--

[Neil Fawcett]

Silly question. Looking a VA, how do I get to these "Special actions"?

ie: If I want to play around and create conditions and assignments, where/how do I do it? I can't seem to find a way of adding them to a command?

Thanks!

[rha...@gmail.com]

Left side, a button marked "Other". Lots of specialty stuff in there.

[Travis Young]

Some of these are only in the beta at this stage. I'm eagerly awaiting them being included in the 'release' version.

--

[Neil Fawcett]

Yes, I've looked in there, but can't see them :(

--

[Gary]

You are going to need the latest beta, Neil.  That can be found here :  http://www.voiceattack.com/beta.aspx

Gary

To unsubscribe from this group and all its topics, send an email to voiceattack+unsubscribe@googlegroups.com.

[Hammerhai]

I played around with your new variable stuff a bit and yes, what you have given us will do the trick. Case statements would come into their own when checking multiple conditions, but are, I agree, not necessary. The cmds should be quite readable for most people, the logic is easy to follow, and I like what you have done. I hope it remains accessible to less experienced users willing to get a bit adventurous.

Thank you for this, and I hope it sees some innovative use in the future. To me VoiceAttack is now the leading command VR product on the market, bar none. Well done.