Not how, but why

[Mike308]

I've been re-reading the VA Help document and watching YouTube vids to understand why one of my third-party voicepacks spent a lot of time/effort building a series of disabled commands (disabled meaning the "when I say" box is not checked and the command is greyed out). These commands are triggered by other WIS commands.

I understand for the most part the mechanics of what they are doing, I'm just not sure why. It seems like considerable extra effort to do what VA can accomplish in fewer steps. Is there a compelling logic argument for separating the triggering 'When I say' commands from the subsequent response actions?

[Gary]

Hi, Mike.

The, 'When I say' option is just that - the command is executed when you say the indicated phrase(s).  The commands can also be triggered on keyboard key press, mouse click or joystick button press.  Each of these options can be enabled by checking the box next to it, or disabled by unchecking the box.

Commands can also be executed as a subcommand (that is, the command itself can be executed from within another command) as well as from a plugin function, inline function or externally (from the command line).  These do not have the option to be disabled, as their use is not from user input but rather from internal operations.  There are options to temporarily disable commands from within a plugin or inline function, but that's a recent addition (latest version, actually).  So, to execute a command without any user interaction (like a function - where the macro is used in several places), you would simply just uncheck all the boxes and call the command from other commands or from plugins/inline functions.

Hope that makes sense o_O

[Gangrel]

I've been re-reading the VA Help document and watching YouTube vids to understand why one of my third-party voicepacks spent a lot of time/effort building a series of disabled commands (disabled meaning the "when I say" box is not checked and the command is greyed out). These commands are triggered by other WIS commands.

I understand for the most part the mechanics of what they are doing, I'm just not sure why. It seems like considerable extra effort to do what VA can accomplish in fewer steps. Is there a compelling logic argument for separating the triggering 'When I say' commands from the subsequent response actions?

Basically it is because we do a lot of command reuse. The "Disabled" commands are building block commands, where they are called/triggered by other commands.

Sure, it is harder work *at the start* but maintenance becomes a whole lot cheaper/faster/easier (delete as applicable) with less hard coding of stuff.

[Mike308]

Gary / Gangrel - thank you!

Thus far all of my commands have been self-contained.
I'd like to learn more about this modular approach and when it would be best applied.
Is there a term for it so I can flex my Google-Fu or search this forum for past posts?

[Gangrel]

It isn't something that is unique to voice attack. It is a form of "object orientated programming" methodology, where you break everything down to small unique blocks and then code for those.

Then you have the "main" programe (profile) which does all the linking of the parts together. Each base command should do just one thing, and one thing only.

Also: It means that you are not rewriting 20million lines of code (again, exceptions happen, our *spoken* commands have a some logic in there, but even so, we still try to keep it to a minimum)... so in our case, if it *was* going to go belly up, it would affect everything (or one class of everything) so it is "easier" to track down as to why it isn't working.

[TheThingIs]

There are 3 main reasons this kind of modular approach was applied to HCS VoicePacks profiles.

1. Updates without user intervention. The biggest issue we always face when providing updates is the complexity this involves along with the frustration when it doesn't work. We want/need to have an update process which updates from one click and everything works and you continue on.
2. 99.9% of our users do not customise commands, they simply customise the voice triggers to execute the commands. Delving into the minefield of editing a profile was not simple enough and people constantly broke the profile. Thus causing us extreme support issues.
3. Languages were something we wanted to do for a long time but having multiple versions of the profiles was simply not possible.

The method we have taken solves all of the above problems. Customising commands must be done in a seperate linked profile which allows us to update without people losing those customisations. Voice trigger customisations can be done seperately in a simple editor and no matter what you put in those changes cannot break the functionality of the commands. Those changes can also be carried through when we update. Languages can be done and switched to instantly, in fact we have a French version being included in the next update.

As you say though, this was a lot of work for something which is essentially already provided. For a personal profile or one shared freely with a few hundred people then this approach is overkill. From a commercial point of view for a product which has thousands of users, it was an absolute necessity

HTH

Lee

[Mike308]

excellent look behind the pro-level curtain... thank you!