Problems with If Statements Not Forking Properly...

Upallnite · Post by **Upallnite** » Mon Jul 25, 2005 7:42 am

I'm not an expert, but I have been writing macros for around 5 years. I started Using Macro Scheduler 2 years ago. I'm running into a problem that has me absolutely baffled. I have a mining macro for the game EVE, I wrote from scratch. Just under 2000 lines. Lately, I'm running into If statements that are not forking to the proper label/srt given.

Example:

Let>vAUTO_Evade=NO

If>%vAUTO_Evade%=YES,Wait_Quick,Wait_Slow

SRT>Wait_Quick
Wait>.250
END>Wait_Quick

SRT>Wait_Slow
Wait>1
END>Wait_Slow

Log Shows:

If>NO=YES,Wait_Quick,Wait_Slow
SRT>Wait_Quick
END>Wait_Quick

I don't understand why all of a sudden, I have dozens of YES/NO If statements all of a sudden forking the wrong way. In this case NO does not equal YES, so it should fork to the second label/srt, but it forks to the first, as though it were true...

The funny thing is that this code works fine alone as a test as well as all the others in my macro. Is there some sort of memory leak, or limit of variables, that could be causing such a problem in a relatively long macro?

Upallnite

It's kinda difficult for me to post the entire macro, but it does have a lot of pixel checking and variables for game/config states...

support · Post by **support** » Mon Jul 25, 2005 8:21 am

Hi,

Which version are you running? See Help/About.

I expect the value "No" has become a variable and been inadvertently set to "Yes" at some point prior to this code in your script. It is therefore possible that No=Yes can be true.

You will find it if you step through the entire script.

Upallnite · Post by **Upallnite** » Mon Jul 25, 2005 10:18 am

The newest registered version with compiler...7.3.11.4

Windows XP
Patched up to date
2048 MB Ram
P4 EE 3.4

support · Post by **support** » Mon Jul 25, 2005 10:53 am

Step through the script and you will find that at some point No is set to Yes. Therefore if vAUTO_Evade is set to No it will in turn equal Yes. Hence your IF is true.

Upallnite · Post by **Upallnite** » Wed Jul 27, 2005 9:55 am

This problem extends beyond just the YES/NO forks, I stepped throught the entire script 5 times checking all YES, NO, and related variables to this error. Still no solution. I disabled all the related lines, and now I'm having problems with other types of logic forks going the wrong way. Such as :

Let>vValue=0
Label>RECHECK
Add>vValue,1
If>%vValue%>5,END
GoTo>RECHECK
Label>END

Code should continue recheck until value is greater than 5 and then end, but it doesn't. log shows 0,1 constantly, without the addition happening, then 0>5, then forks the wrong way. There is seriouly something wrong here...My counter code snippets aren't counting, and I have numerous different types of logic forks, not forking properly. There is absolutely something wrong that is occurring either with the length of my macro, or with the number of variables, that is trashing functionality.

support · Post by **support** » Wed Jul 27, 2005 10:45 am

There's a logical explanation. Need to step throught script, and/or look at log file. Would be happy to take a look at the log file if you post it here or send to support. Also pop a messagebox before the If lines to see the value:

MessageModal>vValue
If>vValue>5,END

And remove the % signs around the variables. No need to have them on their own and certainly not necessary on the left side of a logical expression.

Add MessageModals like the above before all of your If lines so you can see for sure what the values are. In the above if code is branching to END then vValue is definitely greater than 5. Guaranteed. You may think it isn't but clearly vValue IS resolving to a value greater than 5 or could be a string value (e.g. "fred" > 5 too), or may not be assigned at all "vValue" is also > 5).

I expect we can find the issue if you email the script file and a log file to support.

There are no issues with length of script or number of variables. There are scripts in use with thousands upon thousands of lines of code and variables. The issue is that vValue is not what you think it is.