GOTO MACRO LINE Bug???

[stevenm]

I've got a macro that's about 200 lines, and it's deciding to just end the macro if I turn on this new part of the macro (called Box Collection)

I believe the logic is fine, and the clicks look correct.  This is a sample of the macro that is misbehaving:

# Focus is at the top of the macro and does a GET WINDOW BY TITLE to make sure that the app is selected, and then it starts doing everything

* | Before-Box-Collection

149 | RUN ACTION | DEBUG | logger::INFO::DEFEATS: %DEFEAT_COUNTER%

150 | IF | STRING VARIABLE | %BOX_COLLECTION_ON_OFF% | IS | OFF | THEN

  151 | RUN ACTION | GOTO MACRO LINE | Focus

152 | IF | END IF

153 | IF | PIXEL RANGE | At Location [X:951 Y:74]::Size [W:70 H:10] | CHANGES::1::3::500 | THEN

  154 | IF | DETECT IMAGE | image path %IMAGES_PATH%\empty-box.png::match full::move mouse yes | IMAGE FOUND | THEN

    155 | RUN ACTION | DEBUG | logger::INFO::Empty Box Slot (box collection aborted)

    156 | RUN ACTION | GOTO MACRO LINE | Focus

  157 | IF | ELSE

    158 | RUN ACTION | DEBUG | logger::INFO::Running Box collection

    * | Click-Box-Slot-Button

    159 | RUN ACTION | MOUSE CLICK | Left click at 998 130 1 times with 100 ms delay

    * | ClickTroopOpen

    160 | RUN ACTION | WAIT MILLISECONDS | 3000

    161 | IF | PIXEL RANGE | At Location [X:617 Y:323]::Size [W:114 H:105] | CHANGES::1::4::0 | THEN

      162 | IF | STRING VARIABLE | %BATTLE_LEVEL_OPTION% | IS | LEVEL-8000 | THEN

        163 | RUN ACTION | MOUSE CLICK | Left click at 926 447 1 times with 100 ms delay

      164 | IF | ELSE

        165 | RUN ACTION | MOUSE CLICK | Left click at 926 396 1 times with 100 ms delay

      166 | IF | END IF

      * | ClaimTroopBox

      167 | IF | DETECT IMAGE | image path %IMAGES_PATH%\troop-box-ok.png::match full::move mouse yes | IMAGE NOT FOUND | THEN

        168 | RUN ACTION | WAIT MILLISECONDS | 1000

        169 | RUN ACTION | GOTO MACRO LINE | ClaimTroopBox

      170 | IF | ELSE

        171 | RUN ACTION | MOUSE CLICK | Left click at 784 690 1 times with 100 ms delay

        172 | RUN ACTION | GOTO MACRO LINE | Focus

      173 | IF | END IF

      174 | RUN ACTION | GOTO MACRO LINE | Focus

    175 | IF | END IF

    176 | IF | PIXEL RANGE | At Location [X:600 Y:531]::Size [W:116 H:55] | CHANGES::1::5::500 | THEN

      * | HeroBoxOpen

      177 | IF | STRING VARIABLE | %BATTLE_LEVEL_OPTION% | IS | LEVEL-8000 | THEN

        178 | RUN ACTION | MOUSE CLICK | Left click at 926 447 1 times with 100 ms delay

      179 | IF | ELSE

        180 | RUN ACTION | MOUSE CLICK | Left click at 926 620 1 times with 100 ms delay

      181 | IF | END IF

      * | ClaimHeroBox

      182 | IF | DETECT IMAGE | image path %IMAGES_PATH%\hero-box-ok.png::match full::move mouse yes | IMAGE NOT FOUND | THEN

        183 | RUN ACTION | WAIT MILLISECONDS | 1000

        184 | RUN ACTION | GOTO MACRO LINE | ClaimHeroBox

      185 | IF | ELSE

        186 | RUN ACTION | MOUSE CLICK | Left click at 784 690 1 times with 100 ms delay

        187 | RUN ACTION | GOTO MACRO LINE | Focus

      188 | IF | END IF

    189 | IF | END IF

    * | CloseBoxCollection

    190 | 953 | 195 | 2000 | Left Click Down

    191 | 953 | 195 | 100 | Left Click Release

  192 | IF | END IF

193 | IF | END IF

I am trying to understand why the logs seem to say that it's going to the ClaimTroopBox line, but then ends...  This looks to be coming from lines 167 - 169 because I need to wait a few seconds for the image to become available, but want to try every second or so to find the "OK" button to claim the reward and then I can process the next loop of the macro.

11/02/2022 08:43:01.22 PM Macro action - Finished Mouse Click (1 clicks in 0.1144495 seconds)

11/02/2022 08:43:01.32 PM Macro condition: 166 | IF | END IF (9)

11/02/2022 08:43:01.66 PM Macro action - Thread sleeping for 1000 milliseconds

11/02/2022 08:43:02.68 PM Macro action - RunningACTION: GOTO MACRO LINE - Macro line(ClaimTroopBox)

11/02/2022 08:43:03.00 PM Macro playback finished


Also, I was working on changing all the:

191 | X | Y | 2000 | Left Click Down

192 | X | Y | 100 | Left Click Release


To:

179 | RUN ACTION | MOUSE CLICK | Left click at X Y 1 times with 100 ms delay


In case there was an issue with the different syntax, but that didn't seem to help and this seems more like a bug/issue in the GOTO MACRO LINE inside the IF statement (unless anyone can find a problem with my logic).


*  %IMAGES_PATH% is defined correctly and other DETECT IMAGE actions seem to run fine.
* pressing Run Entry on the individual lines in the script seem to work correctly (mouse clicks)

Help?  Should I submit a bug request?

Please and Thank You,
Steven M

[stevenm]

In looking at what is different between this and the rest of the script, it looks like this is the only place where I have 4 levels deep of IF blocks.  Mostly I have 1-2 levels of IF blocks.

maybe related to: MMM_BZ26

Thanks for any responses.

Steven M

[stevenm]

Okay, I restructured the logic so it was only 2 levels deep at any one point, and it works now.

I would suggest this might be related to the For Loop Bug already submitted.  (BZ26)

HTH someone.

Steven M

[joe]

Hey Stevenm,
I think I might be having a similar problem with goto macro lines being skipped.
My macro has over 700 lines of code and a lot of If Then Else statements.

This is a copy of the code that I'm having trouble with:


* | click all games left new

227 | RUN ACTION | WAIT MILLISECONDS | 500

228 | IF | PIXEL COLOR | Color [R=127, G=43, B=25]::At Location [X:44 Y:537] | IS THE SAME | THEN

229 | RUN ACTION | GOTO MACRO LINE | all games left new

230 | IF | ELSE

231 | RUN ACTION | GOTO MACRO LINE | click all games left old

232 | IF | END IF

* | all games left new

233 | RUN ACTION | WAIT MILLISECONDS | 500

234 | RUN ACTION | MOUSE CLICK | Left click at 96 536 1 times with 0 ms delay

235 | RUN ACTION | WAIT MILLISECONDS | 5000

236 | RUN ACTION | GOTO MACRO LINE | favorite

* | click all games left old

* | if website is changed again this button will probably reactivate

237 | RUN ACTION | WAIT SECONDS | 3

238 | RUN ACTION | MOUSE CLICK | Left click at 103 368 1 times with 0 ms delay

239 | RUN ACTION | WAIT SECONDS | 3

* | favorite

240 | RUN ACTION | WAIT MILLISECONDS | 5000

241 | RUN ACTION | MOUSE CLICK | Left click at 779 233 1 times with 0 ms delay

242 | RUN ACTION | WAIT SECONDS | 3

The macro seems to skip over line 236 to line 237.
I think you're saying that the problem is that I have too many If Then Else statements? I'm not really sure how I would decrease the amount of If Then Else statements.

[Steve]

Hi stevenm

Sorry for the late reply and thanks for your help answering off questions on the forum. The community thanks you

I think I can see the problem with your IF blocks. Its the GOTO exit.
Point 2 from the condition www.turnssoft.com/conditions.html#thenelse help page:

Somethings to note with IF THEN blocks within Mini Mouse Macro:
1 - All IF THEN blocks must have a closing END IF.
2 - Once within a IF THEN block it is not possible to escape out with GOTO prior to closing the block.
3 - Classic IF ELSEIF statements are not yet supported at this time.
4 - Statements within IF then blocks do not need to be indented and will work as expected without indentation.

IF blocks in MMM cannot be escaped prior to closing the block. The block needs to close with an END IF. This is due to the linear nature of MMM; everything running top to bottom one line at a time.
Unfortunately this is unavoidable with the code under the hood as it is now. A solution coming in the future would be something along the lines of calling a function block within the else rather than the jump out to the GOTO label.

Hope this helps.

[Steve]

Nov 11, 2022 2:16:36 GMT joe said:

Hey Stevenm,
I think I might be having a similar problem with goto macro lines being skipped.
The macro seems to skip over line 236 to line 237.
I think you're saying that the problem is that I have too many If Then Else statements? I'm not really sure how I would decrease the amount of If Then Else statements.

Hi joe

As above, the issue here is the escaping out with the GOTO condition.

[stevenm]

This is trying to explain what I mean by reducing the number of nested if blocks (and how I did it in mmm)....

If I have something like this with 3 levels of nested IFs:

# typical nested if block (3 levels) -- not mmmacro syntax
if this = that then

  if that = somethingelse then

    if x > 3 then
      dosomething
    end if
  end if

end if




By changing the mmmacro logic to look for stuff in up to 2 nested if blocks, and then defining a variable saying that I found what I was looking for in the 2 nested levels, I can get around the limitation of the 2 nested levels of if blocks by saying something similar to...

found_special_condition = no
if this = that then

  if that = somethingelse then

    found_special_condition = yes
  end if

end if

if found_special_condition = yes then
  if x > 3 then
    dosomething
  end if
end if


The above example and the below example should supposedly do the same thing: dosomething   --->if x > 3 and this = that and that = somethingelse

... but are structured differently to show how I got around the nested levels "bug/limitation" that was causing me headaches.

keep in mind that none of this is in mmmacro syntas but hopefully this gets the point across on what made my mmmacro work correctly for "box collection".

P.S. Thanks for the notes on GOTO and IF..ENDIF caveats, I'm clearly hitting some limits on what the program can do, but I still love the program and it's abilities because I didnt have to write some python or c code to do the mouse and window manipulation code!!!!!

Steven M

[stevenm]

keep in mind that based on what steve (the author) said, I'm likely getting into a VERY deep recursion with all the GOTO lines which is likely causing other problems for me (over time), but in the short run, my macro does seem to be working correctly.

[joe]

Thank you both for your replies.

I understand that I can't exit an IF Block with a GOTO but the first several IF BLOCKS seem to work with the GOTO but later on in the macro the GOTO line gets skipped.
I don't really understand STEVENM'S explanation of how he restructured his macro to make the IF BLOCKS work with the GOTO lines.
I'm going to need some more time to figure this out.

Thanks again for your help!

[stevenm]

by making a variable that is defined IF two levels of IF blocks find the conditions I am looking for, and then having the 2nd level IF block just finish, then I can check from a new first level IF block to check if the first 2 IF blocks found the condition I was looking for

--i.e. whether that variable got set to YES from the second level IF block, and check it from a less nested IF block...  that is how I was able to get around the issue I was having.

I hope that explains it better.

sorry if I am not making sense.

If necessary, I can show you with MMM syntax

Steven M

[stevenm]

Steve, 

If you are sating what I believe you are saying about IF..ENDIF blocks and GOTO statements, I believe following 2 code examples seem to identify the old (bad) way I was doing things, and a way that doesn't violate the GOTO from an IF..ENDIF block case you were warning me about.  Please reply and let me know what you think.

Thanks,
Steven M

#bad - has a GOTO inside an IF block
36 | IF | INTEGER VARIABLE | %RETRY_COUNTER% | GREATER THAN | %RETRY_COUNTER_MAX% | THEN

 37 | RUN ACTION | RUN VIA CMD /C | something

 38 | RUN ACTION | GOTO MACRO LINE | Focus

39 | IF | END IF


# no GOTOs inside an IF block....  is this an acceptable way of handling this scenario???

35 | DEFINE STRING VARIABLE | GOTO_FOCUS | NO

36 | IF | INTEGER VARIABLE | %RETRY_COUNTER% | GREATER THAN | %RETRY_COUNTER_MAX% | THEN

 37 | RUN ACTION | RUN VIA CMD /C | something

 38 | DEFINE STRING VARIABLE | GOTO_FOCUS | YES

39 | IF | END IF

40 | IF | STRING VARIABLE | GOTO_FOCUS | IS | YES | RUN ACTION | GOTO MACRO LINE | Focus