Complicated C#: Where to start...?

[Jishk]

Hello all! I'm trying to build the ultimate _bored rule! I'm hoping to build a VCM just for handling my bot's boredom...

So, I've got a rather daunting task, and was just wondering if anyone had advice they could lend as far as where to start or a way to figure out how to structure everything. As I've stated before, I'm not that great of a programmer, but am more than open to learning if someone can point me in the right direction. Basically, I'm trying to create a _bored rule that executes code in a vcm to do some complex stuff, and am not sure if there's a way to sit down and organize everything I want it to do as far as all the conditionals that are involved and everything. I'm sure I can figure out how to do everything below, but I'm not sure how to do it neatly.

(Or put a little differently, I'm not looking for help structuring it, just looking for help organizing everything so that I can work out how to structure it myself.)

When the _bored input is received, it will:

1) Increment a "bored" variable and check to see if the user is there.

a) If "bored" is under a given value (i.e it hasn't been that long since we last heard from the user), and ask if the user is there.

-Any response will decrement the "bored" value, then <send> the input so the bot will respond normally.
b) If "bored" is over a given value (i.e it has been a long time, several _bored rules have fired), switch to "away mode" (which I guess will just be a bool value) send an email or text asking "where are you?"

2) If the user is at the computer, do the following:

a) Bot checks to see if it needs any info from the user, and asks for it... i.e, "Tomorrow's a weekday and you haven't scheduled me to wake you up. Shall I wake you up at the same time that I did today?"
b) If the bot doesn't need any info like that, the bot checks the user's "to do" list (just a text file) and sends a reminder... "Hey, don't forget that you need to finish writing that thing."
c) If the "to do" list is empty, bot checks the time and gives a reminder to go to bed if it's late on a weeknight.
d) If none of the above fire, just make pointless conversation. (This can be handled through other rules via the <send> command, so I'm not worried about including any of the pointless conversation in the _bored rule or the vcm)

3) If the user is NOT at the computer, do the following:

a) Check to see if it's in "away mode" or not, and check to make sure that the appropriate channels of communication (i.e, skype, outlook, etc) are open.
b) Check if there's anything to be done based on the user's location. I.e, the bot knows the user is at work, and texts or emails "Want me to schedule all the usual stuff for when you get home?"
c) If the bot doesn't need any info, it just makes pointless conversation (again... this can be handled through other rules, so I'm not worried about the pointless conversation.)

I think I should state that "away mode" will basically just a bool variable that, if true, causes "bored" to increment slower and opens outlook with a different profile that has less accounts set up a more frequent send/receive schedule.

Seems pretty complicated, right? Once again, I'm sure I can figure it out and put some code together that can do all of that, but just figured that, before starting, I'd reach out to the forums to see if any of you more seasoned programmers could give some advice on how to lay out how all the conditionals will work and everything.

[JonC]

I think that a lot of this will be doable with a bored rule cascade.
I use to indicate a child rule, thus:
_bored
_bored
_bored
is three cascaded bored rules - each of which can can have a variety of outputs.
Thus reaching a given "depth" in the cascade gives you an automatic trigger-point for a more sophisticated response.
Where this would not match your post is that any user response will "reset" the bored responses because you will jump out of the cascade.
However, if you also include a bored counter in your bored rules:
<?csharp vars["bored"] = (int.Parse(vars["bored"])+1).ToString(); ?>
then you could indeed decrement the counter before a send.
Next time a "bored" fires there are various ways of bypassing the upper level of the cascade.
However, you still have a problem, you will need to decrement, or reset the bored counter elsewhere in your kb, otherwise next time the bot gets bored it will bypass the upper levels of the cascade.
Personally, I'd just let it follow the cascade every time. If you want to avoid the bot sounding overly "mechanical" at this point, just write multiple rule outputs for each level (mine gets progressively more sarcastic as it gets more bored - a bit like me ).

I'm not sure how you check "if the user is at the computer", but setting that aside...
again I don't know how your 'bot stores the info it needs, but (hopefully) this is just a matter of looking at a number of vars-variables and seeing if they are set or unset,
e.g. <?csharp ...
if (vars["wake-up"] == "0000") { vars["sender"] = "<send WakeUp>";
.....
Console.WriteLine(vars["sender"]); ?>
Let me explain that code: it's only one line of several (many?) in the rule output of course, and the lines should be written from low-priority to high (since an unset value further down the list will overwrite one higher up as I've written the code).
What each line does is to assess it the data is unset (I've assumed that a time of "0000" means unset for wake-up time, it could be anything including a blank string) and if so sets another vars-variable to a send command to go get the data etc.
Once the c# has run through all the lines vars["sender"] actually sends the 'bot to the requisite rule to get it's missing data.
To cope with the to-do thing, we initially set vars["sender"] to "<send ToDoList", so that it will default to that rule.
That rule then contains the code you need to handle the ToDo list. Whether this is all c# or a mixture of c# and rule outputs is up to you. (remember that a rule condition like vars["ToDo"] != "" will fire preferentially to an unconditional rule if its condition is satisfied - conditionally true rules are treated as "more true" than unconditional rules by Verbot.
If ToDo is empty then in c# or rule output send to pointless conversation.
---
away mode - that's another rule in the "Bored" cascade - but it's looking more like a tree now, e.g.
_bored
_bored
_bored
Away
NotAway
each of these last two rules would have its own child rules btw
---
Essentially "away" mode is handled in the same manner as the above - but with different variables etc.
Incrementing the "bored" counter (if used) "more slowly" would require a different process. The way I do this (though not with bored inputs) is to have two rules at the same "level" in the kb (the outline above has 4 "levels" - primary rule down to "great-grandchild" if you follow my meaning) which are mutual virtual child rules of each other.
I call these a "counter-pair".
In this case the bored responses would toggle between the rules until a certain value of the counter is reached, whereupon a <send ...> is issued.
If only one of the two rules increments the counter you get "half rate" increments. The simplest solution would be to write one of the two with two rule outputs, one to increment the counter, the other conditionally true if "away" is true is a blank ("<>" works well!).
---
I know that sounds like I'm contradicting my previous "cascade" idea, but there is no reason why you should not change methods part way through! You will need to make sure that the rule prior to the counter-pair resets the counter e,g, <mem.set bored 0>

Hope this helps.

[Jishk]

You know, I hadn't even considered letting the verbots engine do all the work like that... setting up multiple rules like that. I have other sets of rules that are set up like that (just several cascading rules, rules that are virtual children of eachother, etc etc), but the thought hadn't even crossed my mind that I could handle all of this _bored stuff with multiple rules. It definitely seems more doable. Thanks, Jonc!

[JonC]

As the saying goes "there's more than one way to skin a cat."
(btw: this is NOT a reference to animal cruelty - the "cat" in question is a "cat-o-nine-tails" a whip used flog British seamen in the days of sailing fighting ships.)
Glad you found that post helpful.
----

[Somniator]

I already deleted a cascaded ruleset of boredom of my bot because it's frustrated behaviour frustrated me ... and why should I bother myself with negative, at least time-robbing, superfluous virtual conversation?
So I simplified the boredom behaviour. The bot performs some gestures and finally it turns the webradio on.

However, you gave me an idea that might be more clever than playing with the webradio: The bot saves the state of discussion and leaves, i.e. turns itself off. Before leaving it creates a rule named _check_remains_of_past where it stores an output referring to the subject (and/or other issues) and some mem.set commands to restore the present state of discussion.
When it gets restarted the _startup rule sends a <send _check_remains_of_past> command, and this rule (usually stored in the LearnedKnowledge.KB) answers like that: "Hey, seems that you simply went away last time. So I closed my shop too, but I remember that we were talking about [subject]. Would you like to resume this discussion?"

Guess it's a bit complicated and I haven't done it yet, but it is viable, so I think.

[MikeA]

I think storing the subject sounds like a better idea.

Personally, I'm not into the _bored rule as it's not really AI........ it's just a timer. However, remembering the last subject is a nice idea and would impress the user.

[JonC]

Somniator:
That's similar to something I do too: though in my case the info is stored in a variable stored in a csv file.
Next time the 'bot "wakes up" it can remember various stuff about itself etc.

[Somniator]

JonC:

Somniator:
That's similar to something I do too: though in my case the info is stored in a variable stored in a csv file.
Next time the 'bot "wakes up" it can remember various stuff about itself etc.

Just tried out your impressive CSV.kb. I did vaguely understand what happens. There are excellent functions in this vcm that have to be connected in it's practical application. So eg when someone mentions "Ford Fiesta" and the bot compiles the answer "Nice car. It has 3 doors."
BTW I had to change the code of the path/filename in the vcm to get access to the cars.csv. A backslash between path- and filename was missing.

[JonC]

Thanks for the kind words Somniator!
If I only missed a backslash was my only error I'm not going to cry about it!
My "demo kb" is rather primitive actually, and does not demo. all the uses - more keep coming up all the time.
Of course, it has it's own thread:http://www.verbots.com/forums/viewtopic.php?f=7&t=2716
(Some of) the functions are not just limited to csv files either, they can manipulate strings also.