Zugg Software :: View topic - @Var with value of 0 causes expression to return false

Wizard Joined: 15 Jan 2002 Posts: 1644 Location: USA

It works correctly for me
combat=0
#if (@combat = 0) {#echo True} {#echo False}
TRUE

combat=1
#if (@combat = 0) {#echo True} {#echo False}
FALSE

As for the mouseover showing false this is intentional as in most program languages 0 is false and any thing else is true.
0=0 is an expression that evaluates to true and
1 is an expression that evaluates to true but
0 is an expression that evaluates to false and
1=0 is an expression that evaluates to false

Some limitations though when using TRUE or FALSE in the expression
combat=1
#IF (@combat=TRUE) {#SAY True} {#Say False}
True

combat=0
#IF (@combat=TRUE) {#SAY True} {#Say False}
FALSE
#IF (@combat=FALSE) {#SAY True} {#Say False}
TRUE

combat=2
#IF (@combat=TRUE) {#SAY True} {#Say False}
False

In the last example even though combat is a non zero number this expression is false however if you were to write it as

combat=2
#IF (@combat) {#SAY True} {#SAY False}
True

Eventually I will write up a simple guide to expressions in the knowledge base for this site.

[EDIT] Added a little more clarification

Wanderer Joined: 17 Nov 2005 Posts: 65

I know what you are saying, but when I attempted to use the code, whenever the variable was 0 with it on the left side, and I had the "= 0" to the right of it for the criteria expression part of it, it still for some reason returned "False" even though I was expecting it to be "True".

As for the True part, when evaulating rather if a number is true or not, some programming languages does allow for any number other than 0 to be true, such as in VB, even though VB by default uses -1 as true just as C++ uses 1 as true by default.

Sincerely,

Dodgester

GURU Joined: 26 Jul 2001 Posts: 1958 Location: Canada

Wanderer Joined: 17 Nov 2005 Posts: 65

The syntax checking thing had already done that, but it doesn't resolve the issue. However, try to explain why it works when I changed the values from 1 and 0 to 3 and 2 respectively, but if I leave it as 1 and 0, it doesn't? This is working with version 7.21. Given this issue, that's how I been setting up my code in the various triggers and variable interactions. I also been avoiding the 1 and 0 cause of this issue.

Magician Joined: 17 Apr 2005 Posts: 496

Hmm. I copied and pasted your example, added the space, and set @combat to 0 and it worked fine for me. Possibly either @combat is being changed somewhere in the script so that it isn't what you expect when you get to that point (include a couple of shows for bug testing, perhaps?), or you've got a typo somewhere, for example if you're checking #if (@combt = 0) then it would be false because "combt" would be %null, not 0.

Wanderer Joined: 17 Nov 2005 Posts: 65

Well I have already disproved both reasons as I tested it out. For the typo one, as I change the variable's value and then hoover the mouse over the reference to the variable, it shows the changed value, and for the logical error situation (Note, 3 general types of errors in coding, Syntax, Run Time, and Logical), I also have tested it separately. Just wish I could use something like how VBA has it's Debugging tools for break points, intermediate windows and other things. For this here, the only thing that's of available to test is to use the #Echo command, that I know of, so I have had to come up with creative ways to test things out.

Anyhow, just by the simple matter of going from using 0 and 1 to using 2 and 3 respectively, I been able to get my triggers to work properly. This how ever makes it a royal pain as I have to increase everything by 2 to avoid this issue.

That's how I am with programming. When I find an issue, I will first work with it to find out what is causing it, which obviously, one has to look for logical errors as those are the hardest to find out of the 3 general types of programming errors. Once, I find it, I will work on fixing it if possible. If it's not possible for me to fix it from where I am, I will then go onto looking for a work around and avoid the issue like a plague. Normally speaking, this makes the programming work that much harder, but if that's what it takes to make things more user friendly, so be it.

Wizard Joined: 15 Jan 2002 Posts: 1644 Location: USA

Zmud has a built in Debuger and you can add breakpoints and variable watches Windows->debugger

What is the output if you type this into the command line and hit enter

SubAdmin Joined: 18 Nov 2001 Posts: 5182

A lot of time I use the #WINDOW command to send text over to a debug window. On occasion I even keep the debugging output permanently in my script, since it is there for a fault condition detected by an #IF or such. Faults can occur when the mud makes changes so having that custom debug window pop out and report the situation is qute nice.

I have never had a problem with 0 and 1 working the way they should and are expected to. I would suspect some sort of Windows locale setting to be the problem, but that is conjecture and general suspicion of all products made by MS.

Wanderer Joined: 17 Nov 2005 Posts: 65

Given that everyone else had been saying that they never had this sort of problem, I thought I would give it another shot. However, I didn't want to report it right away, but rather give it time to prove to me that it's working properly. Even to now, I still don't really know why I ran into the issue as I did as all I did was change it back to 0 and 1 on one of my variables, which was more or less a simple one and it was the one that I noticed the issue with when I first attempted to use it this way.

Wish I had more information on what caused this sort of issue, so as to determine if it was something on my end or if it was something in the program itself, which has me dumbnified.

Currently, I am running into a few issues, which are really more so on my side, so I still have to deal with those on a one by one basis. However, I noticed the help files in some cases has been of help, but in others, it hasn't been of help (specifically when it gets into more techincal and complex but should still have a few basic things included that it doesn't, thus I had to do a lot of testing around in order to figure out what works and what don't). One such example: How does triggers deal with a variable that is included in the pattern and it's setup as a string list rather than just a single value? I much rather read up on these things via the documentations first rather than go at it blindfolded as it gives more precise direction, saves time in the long run, and it takes a lot of the guess work out.

Sincerely,

Dodgester

Newbie Joined: 26 Dec 2005 Posts: 5

Just some food for thought, but typically for a programming language such as C++, 0 is always considered the integral equivalent of 'FALSE', while 1 is considered the integral equivalent of 'TRUE'. It sounds like some kind of bug, but here's something to try for you that might make it work better.

Here is your old ifcheck from your original post:

#if (@combat = 0) {#echo True}{#echo False}

And here is what I suspect would work for you, assuming your desire is for the TRUE branch to execute when combat is equal to 0:

#if (!@combat) {#echo True} {#echo False}

The expression that would evaluate to the FALSE branch can be made by simply removing the '!' character (NOT operand).

Wanderer Joined: 17 Nov 2005 Posts: 65

Yeah, the space in between was actually caught by the syntax checker as it shows up in red whenever there's a syntax issue. One of the things is that I may not know how the various programming languages works in details, but they all seem to have a lot of commonalities, though also have some differences (some say major, but after seeing so many, it starts looking like more or less the same, just done differently). Even the various emperands and operators could be different among different programming languages. That's one of the reasons why I love to have documentations cause even though some might say it should be common sense, but when you deal with so many, it's easy to get them confused or not know what the true syntax is for a programming language that you haven't worked with all that much. Even if you get the syntax down, next you run into is having to deal with, okay, are all of the objects declared and used in proper manner or are you going to run into some sort of run-time issue, and the last of course is dealing with logical errors. Another reason for documentations is to have some idea how things are suppose to interact in the code, which is the single biggest thing that I generally find lacking in documentations. Documentations tells you the syntax and what it's for, but generally lack how it interacts and/or examples of different types of situations.

Sincerely,

Dodgester.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

The are some definite oddites to zScript. For example this expression (@Lessons>=%item(@LessonPattern,1)) was evaluating to false when the values were 205 and 5 but not when they were 210 and 15. This was because of how %item returns its value as a string. Since all variable values are actually stored as strings and converted to numbers as needed, I realized after a while that the conversion just wasn't happening. The corrected expression is (@Lessons>=%eval(%item(@LessonPattern,1)). This cleans out the quotes that enclosed %item's return value and that allows the expression to evaluate mathematically as I wanted.

It is quite possible that the method you were using to assign combat resulted in some thing similar. We will likely never know though.

Wanderer Joined: 17 Nov 2005 Posts: 65

Thank you for that tip as I shall check it out. I know how that is as I have ran into other similar situations like that within VBA and others, so I have made it a habit of using conversion functions to be sure it's dealt with in the proper manner.

Example:

. . .
On Error Goto ErrHandle
Y = CLng(X)
ESub:
Exit Sub

ErrHandle:
MsgBox "Opps, " & X & " can't be converted to a long integer value.", vbCritical
Resume ESub

End Sub

The one thing about VBA programming, you don't have to declare variables unless you set it as such, which you should declare them anyhow for good programming practice. Normally, it's not an issue when you don't declare, but there are times when it does become an issue as it may try to declare a variant one way, and you intended to have it declared a different way, thus has been known to create either run-time issues and/or logical errors. That's why I have it set as must declare explicitly, which prevents these types of issues.

That's one of the areas that I would like to see improved in zMUD as it does seem to be a bit primative from that stand point of view, both with being able to declare what type of variable (though I do see some conversion functions are available), and what scope level the variable is. Without that, it makes me think of the same type of issues as you have in VBA with Global Variant variables (if not explicitly declared, it's implicitly declared as such, and then the code inteprets the variable based on what is contained in the variable, and the variable is alive during the whole time the program/file is open that the code was written in).

Not only can you run into conversion type errors, but with all of the variables being global, you can run into memory type issue even sooner. Granted, it's not as likely to happen within zMUD given the nature of what it's for as compared to some of the programming work that I have done, which in VBA, it's limited to about 64MB for everything including the code and variables, thus if you get some larger arrays a going (Especially variant types as they take up 22 bytes per location, and it doesn't take much for an array to get large), the program can error out due to exceeding it's memory capacity (this is one of those limitations that I tend to think has been set arbutrarily by MS though, not a natural limitation, but regardless, even then, systems only have so much RAM to work with, thus still would be good practice to help keep that down as much as reasonable can be, not to mention the time aspect that also has to be kept in mind).

Sincerely,

Dodgester