Yes, it’s normal, that’s because the final test cases are different from the ones you can see. You’ll have to check your code again for any possible bugs or inefficiencies.
1 Like
The validator you’re failing is the same validator I shared earlier in this thread:
Sorry I didn’t see it, thank you.
@TwoSteps could you also share validator for “06 Breaker mode”? I’m having some nasty bug I cannot trace…
Thanks
Breaker mode
10 10
##########
# @ #
# #
# B #
# X #
# X #
# B #
# BX$#
# XXXX#
##########
SOUTH
SOUTH
SOUTH
SOUTH
SOUTH
SOUTH
EAST
EAST
EASTHi,
I’m back on Blunder episode 1 where i’m stuck at 91%, the LOOP validator fail,
To understand what i miss @TwoSteps could you also share the validator for “11 LOOP”.
Thanks
here you go:
Loop validator
15 15
###############
# X$ #
# X #
# @ X #
# SW X T#
# XXXXXXX#
# B TS #
# XN W #
# X #
# B #
# B BI NX#
# XXXXXX #
# #
# #
###############
LOOP
Thank you !
This so far, has been my favorite puzzle. Really makes you think about a good logic-tree.
Thank you! 
I think tests are not complete enough. For example, let’s consider this input:
5 4
####
#@$#
#I #
# #
####
The answer should be LOOP. But my solution (Coding Games and Programming Challenges to Code Better), that stuck with an eternal loop on that situation, gets 100% result on the platform.
The same would be if we change ‘I’ to ‘B’ in the input.
The correct solution is here (Coding Games and Programming Challenges to Code Better) - 100% result too.
Probably there’re some more hidden unchecked test cases, but I’m not sure.
in my case it works to clear the visited list every time we break a wall, because this wall breaking updates the map so we can revisit if the map was updated.
HOW does multiple loops work? I have hashed the state of the game with the player state as well as the X destroyed status and it works everywhere except for Multiple loops… HOW and WHY would you be able to complete this maze if you come back a second time at the same position with you and the map at the exact same state?
I think you have missed something. What is the path of Blunder according to your code, and at which point it starts to loop?
I did a bit of debugging, and if I understood the rules correctly, blunder is indeed stuck in a loop.
# ## # #
# #p # #
# # W # #
P is the player position here. The alternative directions are being used (WEST, NORTH, EAST, SOUTH).
Since blunder can not go west or north, he will go East until he hits the next wall. When he hits the wall, the priority West will be chosen, effectively backtracking. Then he will be in the same position and choose east again, effectively being stuck in a loop here.
Did I miss something?
Would you please list out the coordinates from the start? I’m not sure which section of the path you’re talking about.
Here is the output with debug commands (debug info is player x, player y, and whether the alternative directions set is in use):
###############
# #@#I T$# #
# # IB # #
# # W # #
# # ## #
# #B XBN# # #
# ## # #
# # # #
# # W # #
# # ## #
# #B XBN# # #
# ## # #
# # # #
# # W # #
# # ## #
# #B XBN# # #
# ## # #
# # # #
# # # #
# # ## #
# # XBIT # #
# ######### #
# #
# ##### ##### #
# # # #
# # # ## #
# # # # #
# ##### ##### #
# #
###############
SOUTH (4,2) - alt: false
SOUTH (4,3) - alt: false
SOUTH (4,4) - alt: false
SOUTH (4,5) - alt: false
EAST (5,5) - alt: false
EAST (6,5) - alt: false
EAST (7,5) - alt: false
EAST (8,5) - alt: false
NORTH (8,4) - alt: false
NORTH (8,3) - alt: false
NORTH (8,2) - alt: false
NORTH (8,1) - alt: true
WEST (7,1) - alt: true
WEST (6,1) - alt: true
EAST (7,1) - alt: false
EAST (8,1) - alt: false
EAST (9,1) - alt: false
EAST (10,20) - alt: false
WEST (9,20) - alt: false
WEST (8,1) - alt: false
WEST (7,1) - alt: false
WEST (6,1) - alt: false
SOUTH (6,2) - alt: true
SOUTH (6,3) - alt: true
SOUTH (6,4) - alt: true
SOUTH (6,5) - alt: true
SOUTH (6,6) - alt: true
SOUTH (6,7) - alt: true
SOUTH (6,8) - alt: true
SOUTH (6,9) - alt: true
WEST (5,9) - alt: true
WEST (4,9) - alt: true
NORTH (4,8) - alt: true
NORTH (4,7) - alt: true
EAST (5,7) - alt: true
EAST (6,7) - alt: true
EAST (7,7) - alt: true
EAST (8,7) - alt: true
EAST (9,7) - alt: true
EAST (10,7) - alt: true
WEST (9,7) - alt: true
WEST (8,7) - alt: true
WEST (7,7) - alt: true
WEST (6,7) - alt: true
WEST (5,7) - alt: true
WEST (4,7) - alt: true
EAST (5,7) - alt: true
LOOP
There is something I must not have undestood there
After this step
WEST (6,1) - alt: true
my code shows that the next position is SOUTH (6,2) not EAST (7,1).
I found it, the issue was that the inverter was taking effect only the following turn. Weird that it passes the inverter unit test.
This detail isn’t explicitely described in the rules, but let’s be fair it’s mostly an overlook from my side.
Thank you so much for the guidance!
1 Like
i’m sorry could you explain what he meant because i didn’t understand
I don’t get it, I pass every test case in the IDE, except the last one, “multiple loops”
around step #26, the solution of the test case seems wrong to me as when you head NORTH you don’t immediately meet the ‘W’ that would make you turn west.
I tried to follow what’s happening but can’t seem to find what’s wrong in my code