External Communication with Profiles
In order for an external application (or mod to that application) to provide context to a matching profile.
Context could take the form of several things (all temporary):
- Add a
Pronounceableto aSymbol - Enable/Disable specific
Commandobjects - Change internal state of profile
- Resetting profile
Or even:
- Add new
SymbolorSymbolGroupobjects - Add a new
Command
The problem with this approach is that each time the game context changes we will need to recompile the grammar and reload the recognizer. Would it not be easier to have a static grammar and leave it up to the profile script to manage enabling or disabling commands based on context?
We could implement a callback function within the profile script which is called whenever an extension sends context information - it would then be the responsibility of the script to process and store that context and react accordingly (by conditionally responding to certain commands). Alternatively, we could keep a state object which we update ourselves - requiring that extensions send Key-Value pairs over the wire, and treating state like a dictionary.
I agree that it might have a little bit of work behind it, but I think that it'll be worth it. This isn't for the next version but for some version after it. Mostly, this would be used for "broad stoke" kind of context, not small, frequently changing things; i.e. it wouldn't be used for informing that a tank or other enemy has been seen (and enabling commands pertaining to it) but rather that a particular support is available in the mission (and enabling/adding those commands)
There are a couple reasons why having a non-static grammar is a good thing.
- Static grammars tend to be heavier and recognition rate suffers because of it
- Rich experiences, like addressing squadmates by their name, are far more immersive and enjoyable and would be impossible with a static grammar
- Unable to support context-specific commands (like commands specific to an Arma mission)
The technical stuff, I think that we can find a way around. Recompiling a Grammar is relatively fast but reloading it into the SpeechRecognitionEngine has a time cost (that would disable the SpeechRecognitonEngine for a space of time) that I think that could be gotten around by creating a new SpeechRecognitionEngine alongside the old one, loading it up and then exchanging it and disposing of the old one when the new one was good to go.
I had been thinking that the communication would boil down to Lua code that would be forwarded to the particular profile namespace for execution; that way the profile can define its own structures without creating a state dictionary.