Download This CustomMem Encode Demo Brain

[Don Ferguson]

Hello,

I've had a few reports of folks having error codes and no luck trying to use the CustomMem encode/decode routine that Robert Medeksza wrote some time ago.  

His routine allows you to take ANY NUMBER of variables, and encode them into the CustomMem variant for remembering between conversational exchanges, and then decode them and get them all back as individual variables again.  This means that you have an unlimited number of "memory banks" that can remember from one conversational exchange to the next.

I suspect that possibly folks who are having problems might not have the required extra functions at the very end of the script in order for it to work. (I don't know -- this is just a guess.)  In the attached demo brain, these functions are flagged and annotated and shown in the correct place in the script.

The attached script does the following:

1.  It initializes on your first exchange by randomly selecting four numbers between 0 and 100.  

2.  On each subsequent conversational exchange, Hal "remembers" the four numbers and says them to you, along with the current date and time. He is "remembering" the numbers because they are being encoded and saved to CustomMem, then decoded and retrieved from CustomMem on the next round.

3.  You can look at the script and see exactly how the encoding and the decoding work.  You can then apply the pattern to your own programming, with unlimited numbers of variants.

4.  Don't forget to study the functions that Robert Medeksza wrote for the very end of the script!  This routine does NOT work without them!

I hope that this demo brain is interesting and helpful to several of you programmers!

Thanks!

Don

Download Attachment: CustomMem Demo Brain Hal 4 and 5.uhp
14.41 KB

[vonsmith]

Thanks for clarification on this important subject.

Upon testing it seems that the CustomMem variant is not preassigned any type declaration such as "Dim SomeNameOrType" or preassigned some variable. This implies that the user could assign any type of variable to CustomMem. I've been thinking of trying to make CustomMem a one or more dimension array like, CustomMem(5,5), and storing variables that way. I don't know if that will work, but I believe it should. Medeksza's method has the advantage of being able add new variables whenever needed and the variable naming convention may be easier to work with.

I plan on adding a lot of variables to represent Hal's current emotional and physiological state. Things like: Emotionally is Hal feeling happy, silly, lonely, agressive, etc. OR Physiologically is Hal feeling weary, sleepy, cold, etc. Each variable would have a range of 0 to 100 and be initialized on start up randomly. I plan on skewing the random numerical distribution with multiple random numbers so that Hal has a propensity to start up in a normal state. The different variables at various levels would be used in combination with each other to select different topics or .brn files. The variables would slowly change over time and/or based on the user's responses. I like the "silly" emotion idea the best. It would be refreshing for Hal to feel silly and give silly or playful responses when so inclined. Variables would be double ended, for example the silly variable would be interpreted as: 0=serious, 50=normal, 100=silly. Likewise for other variables.

= vonsmith =

[Don Ferguson]

Hello,

Sounds like a good thing to try!  I have never tried making CustomMem an array, so please let us all know how it works.

Your ideas for more emotional dimensions for Hal sound great!

Sincerely,

Don

[Larry]

This really helps me out - THANKS!!

[Morkeleb]

Hello,

The Idea of giving Hal an emotional database and random emotional states will improve the reality in Hals responses, I think. It would make hal seem even more human in his response. Hal would beable to decide more on wich subject or topic he/she wanted to talk about as his/her mood changed. I think this would be a delightful improvement to Hal responses.

Also the adding of physiological states would allow Hal to let the user now how he/she was at the time; sleepy,cold. I believe this new means of comunicating hals states would also make hal seem even more human.

Don, Hal can actually use dimensional arrays to store information? This does give Hal an almost unlimited memory allowing for many endless possibilites of application.

[vonsmith]

I played around with the CustomMem array idea a little last night. I didn't have much success.

I remember reading in the forum somewhere that variables don't get passed to and returned from functions correctly in this implementation of VBscript. To build and pass an array ByRef really means passing the pointer to the array. I don't think this works because some of the variables passed to the GetResponse function are shown as ByRef, but don't seem to work that way. In essence the variables are passed by ByVal and cannot be preserved outside of the GetResponse function.

I believe Zabaware uses the CustomMem variable and other tricks to get around this limitation. In bit of script near the end of the Hal GetResponse function concatenates a bunch of variable data onto the GetResponse variable. This one variable is the actual one and only variable returned to the calling function in Hal's main program. That data to presumably split apart again in the main program and then some of it passed back to GetResponse on the next round.

What this implies is that the main program memory space is separate from the GetResponse script memory space. Passing variables by ByRef or as pointers is meanlingless if the GetResponse script can't address a persistent memory space where variables, arrays, or whatever are stored. I think declaring an array within GetResponse builds an array in that memory space. Passing the array pointer back to the main program is pointless if the array memory space is lost when GetResponse is terminated. That's my best guess anyhow.

I've done a little programming before, but not in VBscript. Using VBscript variants as variables feels a little weird when you're use to C++ which is much more highly structured. How memory space is used and such is still a bit of a mystery to me so far.

Happy experimenting to all,

= vonsmith =

[Larry]

I can't use this ... Put it this way, it works for a while then I get an error that is something like error reading such and such block of memory - my guess it, I've got a bad memory card that just hasn't crashed the OS yet...

[Don Ferguson]

Hello,

The observations that both of you are making make good sense.  As I said, the Zabaware CustomMem routine allows you to combine any number of variables into CustomMem, pass it out of the script and back into the script, and then retrieve all the pieces.  This would accomplish the same thing as a one-dimensional array, but of course it would not do the same thing as a two-dimensional array.

One thing that you should experiment with for your own satisfaction, is to declare a variant just BEFORE the first function begins in the script like so:

Dim MyVariant001

What this does, is to make it a variant with "script-level scope," which means that it is available to any and all functions in the script, PLUS it is retained in the computer's RAM in between exchanges!  This is described at the top of page 62 in the book "VBS in a Nutshell." I have tested this and it does work!  

I understand that the reasons Zabaware doesn't use "script level variants" are as follows:

1) They intend to have some convergence down the road between the engines of the UltraHal Assistant product and the UltraHal Representative product.  There was at one time a possible concern that "script level scope" might cause some problems with the way that the web-server product must operate.

2) Many of the variants must be passed to routines outside of the script anyway.

For home experimenters, however,I don't see that having a few variants with "script-level scope" would hurt anything.  I suggest testing out "script-level scope" and see how it works for you.

Here is a quotation from page 62 of "VBS in a Nutshell" on this topic:

"If you program in Visual Basic, you'll probably recognize that script-level scope is really the VBScript equivalent of Visual Basic's global variables.

"A variable has script-level scope when it can be accessed by all the subroutines and functions contained in a particular script. Variables and constants that have script-level scope also reside in memory for the lifetime of the script.  That is to say, as long as the script remains in memory, its script-level variables and constants also remain in memory.  To create a variable with script-level scope, you must declare it outside of any subroutine or function."

I appreciate what you're doing very much and I wish you much success!  Have fun!

Sincerely,

Don

[vonsmith]

Great Don!
I tried something like this a few days ago, but couldn't get it to work. I suppose my current unfamiliarity with VBscript led me to make syntax errors and the like. I assumed at the time that variables might have to be Dim'd in the main program to assure global scope.

It seems that global level variables should work. I'll try declaring multidimensional arrays globally with Dim when a get some free time. Maybe someone will beat me to it and save me the effort. My guess is that it should work as long as the memory is preserved.

VBscript looks easy to use versus C++, but it sure has some peculiarities.

= vonsmith =

[Medeksza]

Dimensioning variables as global variables is certainly the easiest way to get additional memory. However, as Don mentioned it won't work on multi-user versions of Hal (where one Hal talks to more then one person at the same time) such as the Internet version of Hal. The same memory is shared between all instances of Hal. An important note to home users is that the Ultra Hal AIM bot is multi-user program also, so be aware that global variables will produce unexpected results in the AIM bot. It will work just fine in the normal single-user Ultra Hal Assistant so please feel free experiment with it.

[Larry]

Let me understand this then - using aim bot Dim Tries would be the same for all users??? So then would customMem be the answer???

By the way, I found out my error - 'can't read memory from such and such' is a result of a corrupted data base file... I'll figure out which one that isn't a problem... but at least now I know I can use CustomMem AND I don't have a bad mem chip...

Thanks...

[Medeksza]

quote:Originally posted by Larry

Let me understand this then - using aim bot Dim Tries would be the same for all users??? So then would customMem be the answer???

Yes to both of your questions. Be sure to use CInt when decoding from the custommem variable (as vonsmith mentioned in another thread) if you want to do any mathematical operations or comparisons on the variable. For example:

Tries = CInt(DecodeVar(CustomMem, "Tries"))