$factory:yes, $factory:no

It would be handy to have separate factory rules for just yes and just no in addition to the current yes_no rule. I’m finding a few cases where I want to match one but not the other, and as near as I can tell I right now I have to match both, then put the code in my listener to ignore the one I don’t want.

1 Like

Hey @chris,

Thank you so much for the input! So we can best understand the use cases for this, could you give me a a little more information about the situations you are running into so we can take them into consideration? Also I want to make sure you are setting up the $factory:yes_no rule so it isn’t matching all yes and no responses uniformly if you are not already doing that. This may accomplish something like what you are looking for.

You could set up your rule like in the How To Use Factory Rules in a Custom Rules Text-Tutorial:

TopRule = $* (
      $factory:yes_no {word = yes_no._nl}
  ) $*;

This allows you to set up a Listen behavior to trigger a response off of a variable set to “yes.”

Let me know if you are already doing something like this, I would definitely be interested to see some of the use cases you found for separate factory rules so we can pass this input to the team.


Sure, no problem. I’ve hit two cases so far. Both cases can be handled the way you described above. In one case it adds trivial overhead. In the other case, it’s still not a big deal, but it’s less than elegant.

So, my first case was optionally diverting from the normal flow based on a yes response only. Specifically, “do you need directions?” To minimize burden on the user, I decided I really only needed to provide the explanation if they actually said yes. If they say anything else, I would just move on. In this case, the difference between having a $factory:yes_no and a $factory:yes is really just the difference between having a check for a match and a check for a value, or just a check for a match.

The second case came up last night with my number guessing game, and here’s where it gets more interesting. In the game I have basically four possibilities: adjust the number up, adjust it down, it’s correct we’re done, or you didn’t give enough information, try again. I handle these with a match variable of “higher”,“lower”, or “correct”, using cases based on these, and handle the fourth if nothing else matches. Here’s the rule file for reference: high-low.rule (239 Bytes)

I would like the “correct” case to match a number of possible responses plus a factory yes. So I would like a rule that says something like Correct = ( (you got it) | (thats my number) | (thats it) | yay | <insert factory yes here> );

But it can only be a yes. A no does not provide enough information to make a decision - it needs to go to the fourth case. So, without being able to add just a yes match to my correct rule, I would need to exit the rule with four cases in a match variable (higher, lower, correct, yes_no) plus the value of the yes_no, then check around with the variables after the fact to check if the yes/no matched, then change the match variable to correct if it matched and had a value of yes, and set the match to some bogus value if the value was no. (Or roll the logic down into the case statements, but that doesn’t feel right to me.)

That’s a lot of logic after the rule. It’s not insurmountable by any means. But it seems much more elegant to me to be able to say “match on this, this, this, and anything that sounds like yes”.

(An in-between possibility that I did not see documented, so I don’t know if it exists, would be some way to check and match based on the value of the $factory:yes_no variable from within the rule itself, before returning to the listener. But I gather the rules are really for parsing and substitutions, not logic.)

Hi Chris,

Not sure if this will help solve your exact problem, but I have been able to override the $factory:yes_no with additional options easily using this in my rule file:

TopRule = $* (
    $yesno{yesNo = yesno._yes_no}
) $*;

yesno = ($factory:yes_no{_yes_no = yes_no._nl} | nah{_yes_no = 'no'} | alright{_yes_no = 'yes'});

Does this do what you were looking for? If you’re looking for a working example of this, I use something similar in my shared Look Away skill.

@michael That simplifies a little bit. Essentially it could collapse the yes_no and correct into one thing. I would still have to check for that no value after the fact and adjust.

In my case, I don’t just want to add additional items to a yes/no, I want to strip half of the yes/no away completely.