Fair point.
However, it doesn't really matter, does it? Here's what you just did: Stated a clear requirement, made someone put in time to attempt to fulfill that requirement, then posted additional information which makes it very clear your initial requirement was in fact never going to be the correct solution for your problem.
I know, I'm sorry
When I ran into this problem I was basically going to work soon, so I just wanted to quickly post it on the forums so that maybe someone would answer by the time I was back. Later I realized that it's not very clear about what I actually want to achieve, so I added the EDIT to state it better. I was actually already in the edit mode when you replied. Again, sorry for that.
If you want to keep track of states, use variables and set them according to the state. This is how computer programs work.
Yes, variables would be an obvious solution. I could set an int to keep track of how many times in a row a cmd was used, bool to check if a cmd requires confirmation, txt value to specify the type of a command, and so on.
Well, l'll try to describe my way of thinking and why I wanted to go with a buffer of last used commands. On an example, but let's put user's insanity and repeating the "Hello" aside and get to a functional command:
Command: "[Turn them; ] Back on"
Expected outcome: Execute last used On/Off-type cmd - "{TXT:Action} + On"
where:
(string Action) is a cmd ID, changed with each action-type command, so that we know what was the last executed action
(bool OnOff) is changed with each action to tell if it was an on/off type cmd
Procedure with variables:if(OnOff)
{
switch(Action)
{
case "Lights":
if (!LightsOn)
ExecuteCMD("Lights On");
else say "Already on, sir";
break;
[...] //list of cases for every single On/Off cmd
default: break;
}
}
Now let's say this was the recent cmd input:
Turn off the lights (Action = "Lights"; OnOff=true)
(Random chatter)
Full stop (Action = "FwdThrust"; OnOff=false)
(Random chatter)
Turn them back on
Random chatter is purely immersive thing, it doesn't have to alter the Action and OnOff variable. But the "Full stop" is indeed an action, although not an On/Off one. So in this case, it won't work. The workaround would be to have different versions of Action variable, for example OnOffAction would keep track of last used OnOff cmd. The problem is if I wanted to call the last used action command regardless of its type.
The other problem is that every single command would have to set those variables correctly. With that in mind, if I wanted to add something fancy in the future, I'd have to go through all the commands and add another variable.
Procedure with command stack:String LastCMD = {LastSpokenCMD}
// by the way, I've tested it in the meantime and this token stores the exact command, and the way it was spoken,
// which has its pros and cons, but more on that later
Now I run some analysis of the LastCMD, check it for keywords and apply tags to it (OnOff, Movement, RandomChatter...)
then store it in a database table with, let's say, 10 entries. I could also do something with the {Category} token. If I want, I can blacklist some commands which for some reason I don't want to remember they were used.
Now, the (Turn them Back On) command would look kind of like this:
string cmd[] = cmdDB.Select( "[Type] = '" + "OnOff'");
if(cmd[0]["[ON]"]
{
// here some code to ask the user if he wants to use the previous command instead, because "Lights" are already on
}
else
string cmdToRun = cmd[0]["[Command]"] + " On";
ExecuteCMD(cmdToRun);
So, we have some obvious advantages with this approach. First, if I want to add something, I just add it to the command analysis and modify the DataTable a little bit - no need to edit the profile at all. Secondly, I could handle all the commands from other profiles without users having to adhere to some specific command template that my plugin will be using.
And YES, for the life of me, I didn't use the word PLUGIN even once in my initial post (before edit). That's bad.. really bad..
Well, I think it will actually be best to explain what I'm working on, this might shed some light on why I need all this crazy stuff. I wanted to keep that a secret until closer to release, but whatever. So I'm making an immersive AI plugin. On it's own it would not have much functionality, but it will make using VA profiles more natural. The idea was inspired by A.N.N.A for Star Citizen, she had that "personality" feature that made her responses different depending on her current "mood". The higher the value, the nicer she was to you, basically.
Now, what I'm programming now, is sort of a Master Profile that would interact with other profiles and alter the responses a little bit (provided the external profile is calling a plugin variable to respond, and not a hard-coded value). The AI has few personality traits, that change depending on how a user interacts with her. For example if you are polite (you use "please" and "thank you" a lot) this will make her "kindness" value go up. Most of her responses and the way she adresses you will depend on her personality value.
This is one of the reasons I need to keep track of each spoken command - to catch all the "pleases" and "thankyous" and alter the personality. This is also a reason, aside from aforementioned functional value, why I need to keep track of a number of recent commands, regardless of the profile they were called from - to prevent users from "spamming" one command just to "farm" her personality. And I just realized, for that I need the spoken phrase (LastSpokenCMD will do) as well as the full command identifier, so that I have a way of telling if it was the same command but with different initialization phrase.
So I actually DO need this command ID somehow. If not possible, I think I'll just go with your suggestion to check the {LASTSPOKENCMD} token in a loop, and just pass it to plugin whenever it changes. I already have the personality handling down, the functions to select correct phrases from database based on personality (a method to let the users add their own response phrases with personality requirements is in the works). The only thing I need now is a way of tracking the used commands.
Wow that ended up much longer than planned o.O
TL;DR:
- IT"S FOR A PLUGIN (should've mentioned that earlier, I know)
- variables won't work
- I do need the command ID to store in the DataTable
- That {LastSpokenCMD} loop helps
Unless I've overlooked some important detail, in which case please point this out or suggest a better way of achieving my goal.