One of the main reasons for some of the new Conditional checks is that I was always annoyed with the whole random log system. And I did not want to break that system just to suit my own desire to make it work better. Hence, two new conditional checks were created.

34: $LOGFILE: if logfile {#0} contains {#1} compared to {#2} records
35: $LOGFILE: if logfile {#0} contains {#1} compared to {#2} entries in record {#3}

 And armed with this, plus some commands that WolfScript was lacking, I was ready to design a random system where the bot would cycle through the list once before repeating itself. Plus, because I could now use a normal logfile system, I also have the ability to extend the list on the fly without regenerating it.

DMG has a function, well, a couple of functions, in which when you give the bot a cookie, it says something really odd or strange, then clones your colors. I used to use the [randomlog:(filename)] feature, but the problem is that the potential of repeats is high, I have seen the bot say the same thing with two successive cookies. So, now the rebuild:

Trigger Name: Spot Loud Cookies
 Stop Action Search if TRUE
A channel message is seen {@cookie}
AND:
    if variable {[word5]} is the same as {Dream|Makers|Guild} _
(text comparison)
THEN:
      Execute Procedure {Cookie Action}

Trigger Name: Spot Silent Cookies
 Stop Action Search if TRUE
A channel message is seen {@cookie}
AND:
    if variable {[startingword3]} is the same as {just gave you a cookie!} _
(text comparison)
THEN:
      Execute Procedure {Cookie Action}

And that's how you determine if someone has given the bot a cookie. There is an intristic flaw with those two checks, and that's the missing third command, when someone gives a silent cookie with a message.

Dream|Dancer just gave you a cookie! It has a note attached which reads: and this is with a message

But that can be overcome with the availability of yet another new Condition Check:

    if variable {[message]} contains text {just gave you a cookie!} _
(case insensitive)

Which means that when I figure out exactly how I want to handle that, I can also use the message to select from which randomism I want to have to bot use when getting a silent cookie, with a default if no selector is given.

So, the next step is to fetch the Randomism. As you can see from the above two commands, rather than duplicate code between the two detectors, I call a proceedure to execute my desired actions on getting a cookie from someone.

Trigger Name: Cookie Action
Procedure
   No Additional Conditions.
THEN:
      Say {cookies-reject}
      Store {TRUE} to variable {[validlook]}
      Store {TRUE} to variable {[blind]}
      Set countdown timer {UnBlind Bot} to execute in {900} seconds
      Store {[word2]} to variable {[cookiedonor]}
      Set countdown timer {Cookie Look} to execute in {2} seconds
      Execute Procedure {Get Random}
      Say {[saythis]}
      Execute Procedure {Reset Randomism}

Everything above is fairly straight foreward, the two timers I call on are for executing the cookies-accept after 15 minutes, and making the bot look at the cookie donor. There was a reason I stuck it into a timer, just can't remember why now. Then I execute another proceedure which fetches the random remark from the file, say what was fetched, and then I reset the randomism? No, not really, that's where the new Conditional checks come into play:

Trigger Name: Get Random
Procedure
   No Additional Conditions.
THEN:
      $LOG: Set variable {[avails]} to contain number of entries _
in record {Randomism} in file {[scriptdir]random.log}
      Store {[add:[random:[sub:[avails]:1]]:1]} to variable {[saywhat]}
      $LOG: Set variable {[saythis]} to contain evaluated entry {[saywhat]} _
from record {Randomism} in file {[scriptdir]random.log}
      $LOG: Remove log entry {[saywhat]} from record {Randomism} in file _
{[scriptdir]random.log}
      $LOG: Save entry {[saythis]} to file {[scriptdir]spoken.log} _
under record {Used}

Now this rocks, I get a random entry from the log, then remove it from the random log and stick it into the used file. So that makes the most of the randomism and ensures that it don't repeat until the log is empty and it has to reload it. From the used of course. Note that I did it as two logs, it can easily be done with one log, the randoms and the used. So what is up with the Reset Randomism?

Trigger Name: Reset Random
Procedure
AND:
    $LOGFILE: if logfile {[scriptdir]random.log} contains _
{Exactly} compared to {0} entries in record {Randomism}
THEN:
$ Begin Wolfscript: (1)
// reset random log from saids
&newvar #destination &getvar(scriptdir)
&newvar #source #destination
&join #destination {random.log}
&join #source {spoken.log}
&newvar #work
&newvar #count &txfindrec(#source Used)
&for #index=1 to #count
  &set #work &txgetentry(#source Used #index)
  &txsavelogentry #destination Randomism #work
&next #index
&txrmall #source
&display {Random Log Reset}
$ End Wolfscript: (1)

Ahh, there we go, the proceedure does not execute unless the Random log is out of entries. Clever. And once it's called on with the log being empty, it executes a WolfScript loop to transfer the entries from the used file back to the random file. And then resets the used file, that's the TXRMALL which is TeXtReMoveALL command, same thing as $LOG: Remove all logs and all records from file {filename}. The new WolfScript commands above are the TXSAVELOGENTRY FileName RecordName EntryData and that NEXT because I kept using NEXT and being annoyed that I never put that in.

Ta Da!