This was fun. Even the debugging was fun. Even though the example was once again naughty, at least for Part 2, this was fun. (If anyone’s input creates a cube in the same way as the example, I’d like to know!)
Only one hint / comment from me: in part 2, at first I forgot to change orientation when moving from one face to another.
I thought about drawing the paths onto the map, but it’s pretty late where I am, so maybe tomorrow. In lieu of that, here’s an aid I made to help with Part 2.
Worked on some visualizations, but the path is too long to follow easily. I tried animating it, but that didn’t really help, or, the resulting file size is just plain too large.
I have some ideas for how to improve the visualization, but if anyone wants to see what I have in the meantime:
Also open to other suggestions…
Probably it would be slightly overkill (although if you play AoC, it’s probably already too late to hope reaching any limit of overkillness), you could display the path with GLOBE_3D (or plain GL if you prefer), 2D or 3D, and make a video capture of it. The package GL.IO that you find with GLOBE_3D provides such a facility (cf the Start_capture, Capture_frame, Stop_capture procedures), in Ada (no dependency on hardware type, drivers, …).
Glad to be done with this one, I had a few mistakes in part B and because of the way I wrote it I couldn’t use the test data.
I made a similar aid, but didn’t tape mine because I had to keep unfolding it to figure out where I was.
My turn (see below).
The different cube mapping between the example and the input is a bit borderline IMHO.
So… when I was done with the example’s cube and with the painful debugging the 24 transitions’ arithmetic, well — surprise! The input’s mapping is not a larger version of the example’s (insert here a meme with someone shouting “Nooooooo”!). Is the author making fun of the poor coding addicts?! The fun level has reached such a low that I have decided categorically to stop playing this game. Enough is enough! Or, at least for this year, for sure. OK, perhaps just skip today’s second part.
Well, as you see, the protest did not last for too long and the solution, accidentally, supports the example and the input I have received (an enum does the switch). A positive outcome is that the transitions are much more compactly programmed and idiot-proof easier to debug.
Yeah, I dunno. Maybe. I already sank a couple of hours into trying to get ImageMagick to produce the animation. Nice that it’s written in Ada, though!
Yours looks sturdier than mine. I think I managed to avoid unfolding by labeling the sectors, both on the cube and on a separate sheet of paper, and using the labels to keep track of where I was. You’ll see them as circled numbers in my photo (1, 2, and 3).
That intimidated me, too. I didn’t take the time to write Part 2 so that it would work with the input; I decided that was too much trouble, with no obvious payoff. It’s impressive that you took the time to do it, and with any luck we’ll make it through the last puzzle!
I had already figured out that my puzzle input didn’t match the test data, and that I would just have to go with my puzzle input. I had also decided that I would just focus on my input and not make one that could handle any input. I did toy with the idea only doing part one, but eventually relented.
I managed to get visualizations that are both meaningful and relatively small in size! The main thing to notice is how the wrap-around occurs: in the first image, it goes strictly up-down or left-right, but in the second, the path will exit one end and enter on another end that clearly is not strictly up-down or left-right.
