Overflow error in gold counter

I keep getting an overflow error in my gold counting sub-routine and I can't figure it out. I thought a long variable was supposed to be able to hold up to 2,147,483,647? I only had around 1,000,000 gold on me and I had gained 15,000 gold from a mob, so this sub-routine kicked in:

Sub OnReceiveGold(strTriggerName, strOutput, arrWildCards)
gold = cLng(gold) + cLng(arrWildCards(1))
End Sub


... and I got an overflow but I see no reason why I should have an overflow. If anyone can help me with this I would really appreciate it. Thanks.

It may help if you additionally include your trigger and the full line that it triggered on so that the entirety of the process can be checked.

I should've included them originally, sorry about that.

My Trigger:

^You get (.*?) gold coins from (.*?) of (.*?)\.$

The line sent by the mud:

You get 15002 gold coins from the burnt corpse of the troll.


All the trigger does is call the OnReceiveGold sub-routine and as you can see, it simply does this one calculation.

And where is "gold" defined? Do you have:

dim gold

somewhere in global scope?

Yeah, I have gold defined as a global variable. Right at the top of my script, before any subroutines, I have dim gold.

I cannot reproduce the problem. Trying in immediate mode the following, which approximates what should have happened to you ...


dim gold

gold = empty

'
' get gold up to 1000000
'

for i = 1 to 100
gold = cLng (gold) + cLng (10000)
next

' try adding the extra bit

gold = cLng(gold) + cLng ("15002")

world.note "result = " & gold


I get the result:


result = 1015002


Thanks Nick, I'll just have to take a harder look at my script and see what else could be causing it. The only thing is that when I initialize the gold variable I have:



whereas you have:



I've only been using VBScript for a little while so I'm not very familiar with it, am I supposed to initialize variables with empty or is something about the way I initialized mine producing a problem? Thanks for the help.

gold = cLng(0)

looks great to me.

All I can suggest is adding a "display" to the trigger (the script or the trigger itself).

eg.

Wildcard 1 is %1

Set it to "send to output". Then you might find if a bogy number is making its way through.

If that is the case you could make the trigger a reqular expression and look for numbers only (eg. [0=9]+ )

I hate the fact you can't specifically cast variable to specific types explicitly. I have run into the same problem with one of my scripts and it all comes down to the way VBscript guesses what you need, instead of doing what you tell it to.

another example>

a = "1,2,3,4"
b = "2,3,4,5"
c = split(a,",")
d = split(b,",")

e = c(2) + d(1)

In some cases like above you get an error, despite the fact it should work, but if you do:

e = Cint(c(2)) + Cint(d(1))

you may end up with 3, instead of 6, because the scripting engine gets confused, decides that d(1) is a string and returns 0 or something...

So some rules of thumb (in theory)>
1. If you don't yet have a value to put in a variable to start with, don't try to use cLng(0) or the like to cast it. VBscript will prabably return a long, but realizing that it will fit into a regular integer, will cast the variable to fit the value itself, not the type you intended.

2. Don't use stuff like a = 1 or a = "Hello", etc. without first using dim a. For some reason plugins won't let you do this, even though it is perfectly valid and will work correctly in a normal script. (Is this something resulting from the way you did the plugins Nick?)

3. If you need to use an element in an array, use a temporary variable to store the value for calculations, so it won't get ignored.

4. Also with arrays. A split array is 'apparently' somehow different than one that has been defined directly, thus you can't expand or contract it with 'redim preserve <array>(new size)'. It will resize (maybe), but does not preserve the contents of the array as it should. This means if you need to do such a thing, you literally have to make a new array that is the same size, copy the split array into it, then resize the temporary one. It is generally easier to
avoid this completely 'if possible'.

There may be other quirks as well, but these are the ones I have run into. Almost makes one wish there was an alternative version of basic that ran as a COM based script language. :p

In the constants.vbs file which you probably included is a line:


option explicit


This line makes sure you dimension all variables. I can't see a reference to turning this off in the help, in fact it says it must appear before any other statements.

You could take it out of constants.vbs, but it is probably good practice to leave it there.

In fact, you are better off adding it to the start of all your scripts. That way you can catch spelling errors where you think you are using one variable but are really using two.

Thanks for the help Shadowfyr, I'll have to keep an eye out on some of those "quirks" you mentioned about VBScript. :)

Ah.. Didn't think of that being in there Nick. That would definitely explain it. lol It also explains why one that I built by hand before the wizard was out actually does use the short cut and actualy works right.