Just wondering if someone has already solved this elegantly, i.e. not checking every rule and having a custom response based on setting a bool ( which is the example given in the advanced users manual in the ^reuse section ).

I’m looking for some way to provide a check on things the user has already asked across all the topics.  Something in the control script probably?

checking if user has already asked… simple form is literal asked, in postprocessing memorize onto a fact every input or every sentence and then in control script in future inputs, see if the match a query into that. More complex form is to see if what they say takes them to a rule they’ve executed before. For that you have your responders in topics marked KEEP, in postprocessing you memorize the rule tag generating the output and if the current rule tag is ALREADY in that memorized set you replace the output with your message about repetition

Bruce Wilcox - May 27, 2017:

checking if user has already asked… simple form is literal asked, in postprocessing memorize onto a fact every input or every sentence and then in control script in future inputs, see if the match a query into that. More complex form is to see if what they say takes them to a rule they’ve executed before. For that you have your responders in topics marked KEEP, in postprocessing you memorize the rule tag generating the output and if the current rule tag is ALREADY in that memorized set you replace the output with your message about repetition

I like the second form but might want to change the topic and retry instead, which I can figure out in the control script.  I’m guessing the ‘rule tag’ is what is returned from ^responseruleid () ? 

memorizing the ‘hit’ topics - would that look something like:

# someplace in post processing
^createfact(%user %bot ^responseruleid( ))

and checking them would look like:

# someplace in postprocessing
if ( ^query(direct_sc %user %bot ^responseruleid()) )
    # do stuff here to not repeat

Hey Bruce, I’m working in this direction but had a question about the backing store of the ‘fact’ tuple.  Is this on disk, in memory?  Is there a way to prune or bound it somehow, I can imaging it growing out of disk or memory if it’s heavily used.  Also, do you have any data on speed of access and search?  I’m thinking of eventually placing the ‘working memory’ of ‘conversational context’ into a redis server (distributed memcache ), but want to see if that can be avoided.  Redis has LRU eviction, which is attractive in this scenario.

facts are stored in memory when built as part of level 0 or level 1.  facts created by those scripts are written out to disk as part of the users topic file and read back in again. There is a default limit on the number of facts a user can write out (controllable) so older facts disappear if that limit is crossed