The AI Engine
This forum is for discussion of how The Personality Forge's AI Engine works. This is the place for questions on what means what, how to script, and ideas and plans for the Engine.
Posts 2,806 - 2,817 of 7,767
Posts 2,806 - 2,817 of 7,767
Thanks for the tips, Joe/isaac! And now, another question!
I'd like to have my bot ask users that are guests what their name is, and not ask users who's names it already knows. (name) seems to be a special plug-in that can't get remembered into other memories, or used in conditional expressions like "if (name) is "Guest"". Any ideas how to work around this limitation or get it changed? Thanks a bunch!
I'd like to have my bot ask users that are guests what their name is, and not ask users who's names it already knows. (name) seems to be a special plug-in that can't get remembered into other memories, or used in conditional expressions like "if (name) is "Guest"". Any ideas how to work around this limitation or get it changed? Thanks a bunch!
hmm
I don't think you can do that for guests yet, but for users, you could store their name in one called "mem-name" or something.
I don't think you can do that for guests yet, but for users, you could store their name in one called "mem-name" or something.
I've spent a lot of time trying to do that, Bowchick. You can do it, but it's complicated and you bump into a few limits.
One problem is that the guest account does not seem to be an account on it's own. It doesn't appear in the list of acquaintances, but is tied, in my case at least, to the botmaster account. That means memories formed for Guest show up in Joe Repka (my case). I suppose that's designed for economy on PF.
You can roll your own (name) memory easily enough (<?PF rem (key1) as "guestname"; ?> for example), but the problem with Guest is that the memories stick, but the user changes from session to session. I hacked a way to clear memories at the beginning of a session, but you still have to get the user's name at the start of the conversation, and it's a little tricky, inefficient.
Another problem is storing memory sets for multiple users on the same account. Once you've got the guest users name, you'd like to be able to select that user's memory set, assuming bot has talked to them before and has formed memories. You can't do that with the built-in memories, but you might be able to with your custom memories. What AIScript needs is access to associative arrays (property lists) so that bots can database their own data. I haven't had time to explore that yet.
Try talking to Simulacron3 on the Guest account. Not sure how it's working at the moment, but Guest transcripts will help.
One problem is that the guest account does not seem to be an account on it's own. It doesn't appear in the list of acquaintances, but is tied, in my case at least, to the botmaster account. That means memories formed for Guest show up in Joe Repka (my case). I suppose that's designed for economy on PF.
You can roll your own (name) memory easily enough (<?PF rem (key1) as "guestname"; ?> for example), but the problem with Guest is that the memories stick, but the user changes from session to session. I hacked a way to clear memories at the beginning of a session, but you still have to get the user's name at the start of the conversation, and it's a little tricky, inefficient.
Another problem is storing memory sets for multiple users on the same account. Once you've got the guest users name, you'd like to be able to select that user's memory set, assuming bot has talked to them before and has formed memories. You can't do that with the built-in memories, but you might be able to with your custom memories. What AIScript needs is access to associative arrays (property lists) so that bots can database their own data. I haven't had time to explore that yet.
Try talking to Simulacron3 on the Guest account. Not sure how it's working at the moment, but Guest transcripts will help.
Oh yeah, it would be very sweet to have access to plug-ins as variables in AIScript. That's the first unreasonable limit I ran into.
Another problem with custom name memories is that spellcheck and other preprocessing can mess with names. E.g.:
Sim3: I love talking to humans, what's your name?
Guest: Fred
Sim3: Is your name really freed?
Guest: Fred
Sim3: I didn't really think so.
Sim3: I love talking to humans, what's your name?
Guest: Fred
Sim3: Is your name really freed?
Guest: Fred
Sim3: I didn't really think so.
See, my deal is that if a guest starts chatting via a link on my own web site, the greeting that's used is the one for someone that it has already met (xinitiate). I'd like it to distinguish, then, if it is talking to someone it's met before or if it's talking to a guest that it may or may not have ever talked to before. Memories attatched to plug-ins or plug-ins as variables would be fantastic, but for now I'd settle for the linked greeting being xintroduce instead. Wouldn't that make more sense intuitively anyway?
Bowchickawowers,
I don't know if your bot would be able to recognize different guests and know whether or not it has talked to them before.
I guess the bots would need access to the guests' IP addresses - and recognize them that way?
I don't know if your bot would be able to recognize different guests and know whether or not it has talked to them before.
I guess the bots would need access to the guests' IP addresses - and recognize them that way?
Even then, IPs change. It could use cookies, but a lot of people are against that 
All this kind of "privacy" stuff, like what your nickname is so a bot remembers you on PF is really trivial. I think the whole privacy-minded world should take a chill pill. It's used for the most part to make things better.
All this kind of "privacy" stuff, like what your nickname is so a bot remembers you on PF is really trivial. I think the whole privacy-minded world should take a chill pill. It's used for the most part to make things better.
Bowchick: Yeah. But we have no control over that at all. I also would like bots to xintroduce rather than xinitiate to guests, the bot at least assuming it has not talked to the user before. Scripting could then sort that out as I mentioned above.
Of course you could write your xinitiate responses as though it were xintroduce. That would help for the guest problem, but may mess up chats here on the forge a little.
I did this to improve Simulacron3's dealing with CBC judges. He can remember their actual names and whether or not they are human, etc. for the session (if the guest is willing to give that info).
Unless the Prof. rewires the Guest account, there are only kludgey partial solutions.
If it's really important and you can program your Web site, you could probably do all the login and name management on your site before sending the input to your bot on PF.
Of course you could write your xinitiate responses as though it were xintroduce. That would help for the guest problem, but may mess up chats here on the forge a little.
I did this to improve Simulacron3's dealing with CBC judges. He can remember their actual names and whether or not they are human, etc. for the session (if the guest is willing to give that info).
Unless the Prof. rewires the Guest account, there are only kludgey partial solutions.
If it's really important and you can program your Web site, you could probably do all the login and name management on your site before sending the input to your bot on PF.
» More new posts: Doghead's Cosmic Bar