Its not mistake. Very attentively read this:
“Bender can also find a few beers along his path (B on the map) that will give him strength and put him in “Breaker” mode. Breaker mode allows Bender to destroy and automatically pass through the obstacles represented by the character X (only the obstacles X). When an obstacle is destroyed, it remains so permanently and Bender maintains his course of direction. If Bender is in Breaker mode and passes over a beer again, then he immediately goes out of Breaker mode. The beers remain in place after Bender has passed.”
Hello,
I had the same problem and also commited suicide. After all, I found a test that cought the bug in my program:
6 6
######
#X$XX#
#X@XX#
#X XX#
#XXXX#
######
My algorithm looped on this one, because my priority search returned the new direction even if the object in that direction is ‘X’ (but I exclude the current direction). Strangely it passes everything else 
Hello guys,
I’m having the same problem as @DollarAkshay, which is I’ve passed all the test cases, but not the All Together Validation Test when I submitted.
Can I kindly ask for the data is used in the All Together Validation Test, or some advices on this matter?
Codingame likes to give you test cases that don’t include certain edge conditions while you’re testing, and then throw those edge cases in during the actual validation. Chances are you ran afoul of one of them. Unfortunately, the test case data isn’t available, so you’ll need to examine your code and do some what-if work.
Try to think like an evil genius. If you were intentionally trying to make someone’s code fail, what would you do? Can your code handle having Bender pass over the same spot from different directions without calling it a loop? With and without breaker mode activated? Before and after breakable blocks get destroyed? I don’t know if any of that is actually necessary, but it is all possibly important. If your code is failing, you might want to take oddball stuff like that into account.
Other things to check: is there behavior in your code that allows some conditions to be incorrectly detected? A greater-than where you meant greater-than-or-equal? Is it possible that a null can slip in where it isn’t expected and cause weird behavior?
If you catch me in chat and coded in something C-related, I’ll be happy to have a look at what you have.
My code pass all the test cases but I only get 91% and fail in validator number 6, breaker mode, after I submitted my solution. I cannot access the map of the validator thereby have no idea where is the bug. Can someone help me to finish the whole task?
I had exactly the same misconception. Would it be possible to change the first example in the rules so that it makes it clear that current direction is not taken into account in the priorities?
Hi there, im passing 100% of the IDE tests, but when i submit I failed on “all together”;
locked on 91%, My algo is fucking simple ( 35lines in php ), so I dont see where I can fail. I check everywhere, im stuck…
The only touchy part of this puzzle is the loop detection, so there is a good chance that your issue is here ^^ (false loop positive?)
@FredTreg
The only test i don’t pass is the teleport one, and only in the validation stage.
All I do once he moves onto a ‘T’ is change his coordinates to the second ‘T’ leaving everything else the same, direction and state included.
Any ideas, suggestions?
Just changing coordinates should work. Recheck your code - do you read teleporter coordinates correctly, do you actually change coordinates to a different teleporter, does your code work correctly in regards to loop detection, when teleporting is involved?
If your teleportation code is correct, the fail might not be related to teleportation, despite the validator name.
The most tricky part is loop detection, so check that code as well.
i detect the loop by keeping a log of positions, direction and states. Once it repeats a position, direction and state i consider it a loop (I clear the log every time an obstacle is removed). I don’t see how it can affect a teleport but i will look into that.
as far as getting the teleport values correctly, I keep them in an array and get the one that does not match my position, so i don’t see how it can go wrong, but once again I will double check there.
From past experience it’s bound to be one of those mistakes we look at repeatedly and still goes unnoticed.
I do handle the loops and teleports the same way as you are describing it.
How efficient is your loop log lookup? Might it be a timeout issue?
One more thing that has come to my mind - how do you get the output? might it be the case that you calculate output by difference between coordinates for each step, and teleport can screw it up?
Hi,
Can you please tell me why the following test fails with the given input and output below?
Bender, a depressed robot - fails test 04 - Straight Line. Am I missing something or is the test wrong?
Console output
Standard Output Stream:
########
@
XX
XX
XX
$#
########
EAST
EAST
SOUTH
EAST
SOUTH
EAST
SOUTH
SOUTH
Failure
Found: S
Expected: E
Thank you,
C
From the problem description:
When Bender encounters an obstacle, he changes direction using the following priorities: SOUTH, EAST, NORTH and WEST. So he first tries to go SOUTH, if he cannot, then he will go EAST, if he still cannot, then he will go NORTH, and finally if he still cannot, then he will go WEST.
In step 3 you change you direction without encountering an obstacle. You should just keep your current direction instead in this case.
Also: You can look what the expected output is for every testcase when you click that little symbol between “CUSTOM” and “Actions” in the IDE, it will show you that the correct output would be:
EAST
EAST
EAST
EAST
SOUTH
SOUTH
SOUTH
SOUTH
Oh! So, if Bender is currently moving East, he stays going east. But when he hits an obstacle. He doesn’t try North next, he resets to trying South, then East, then North, then West?
That is a bit weird, but explains my problems.
Your example problem should show him resetting priorities from East to South, I think.
Finally managed to finish it. Loved this puzzle. I especially like how it builds up. I wrote my code so that the first couple of tests passed, and then just added more bits to handle the additional characters and conditioning. For me, the hardest parts were properly detecting and reseting the direction to try, and the fact that beers are NEVER picked up. Infinite beer!
Hey, I’m probably misunderstanding rules of Bender game - when take the second map witch looks this way (B as Bender):
‘########’
‘#▯▯▯▯▯▯#’
‘#B▯X▯▯▯#’
‘#▯▯X▯▯▯#’
‘#▯▯XXX▯#’
‘#▯▯▯XX▯#’
‘#▯X▯▯▯▯$#’
‘########’
So Bender should head first south, ends in lower left corner; try current direction(#, false), south(#, false), east(X, false), north( blank, yay!) and go all the way to north and there tries current direction north(#, false), south(blank, yay!) and that repeat over and over again. Is it corrent? It doesn’t look like that way 
Well, nevermind - dont forget that first scenario works in both correct AND transposed maze (:
Thanks!!! I spent hours trying to figure out what I was doing wrong. I definitely did not understand this rule from the instructions. You’re awesome!
Hi,
I have a problem in understanding some rules. In a map like:
10 10
‘###########’
‘# S W #’
‘# #’
‘# $ #’
‘# #’
‘#@ #’
‘# #’
‘#E N #’
‘##########’
the solution should start with 2x SOUTH followed by 6x EAST.
My question is why 6x EAST when there are 5 spaces between E and N.
It should be 7x EAST followed by a NORTH and not 6x EAST followed by NORTH because you move to E but only on the next step you display EAST and when you encounter N, you should move to N(display EAST) and next time you display NORTH after you move from N. Am I right?
The example provided is doing like this 