I'm happy to use Alteryx even in the weekend.
REGEX_Replace([Concat_Object], "(^.*#[^#]*?)(\.?)(O*@)$", "$1$3$2")
Part2: Starting from "@", trace the objects until reaching to "#". I had to use nested Iterative Macro, and logic was complicate when moving upward or downward.
To be honest, I admit my WFs still have much room of improvements. It takes too long time execution (30 min).
(EDIT)
Optimized my WF for Part2: 7minutes. I could not make it faster any more.
My solution.
It takes about 7min.
In part 2, I added a few more conditions.
 
 
Day15. More in spoiler
P2: It took a long time to figure out an approach. I knew I needed some dynamic logic to connect the vertical moving blocks that weren't aligned. My nested macro looks at the current point, next point, and next corresponding point (for instance if the next point was '[' the corresponding point would be ']' and then assigns the proper column. Then I'd loop through each combo until I hit a '#'. The results of this macro gave me all the data points affected by a vertical move. This allowed the block to move as one step and determine if they'd hit a '.' or a '#'. Left/right/up/down with no blocks impacted were the same from P1
17 min run time before I could optimize.
This one was a bit of a beast... happy to have managed to get almost all of it done while riding shotgun for two long car rides yesterday as well... and special shoutout to my fiancé for driving and letting me work on Advent of Code.
Part 1 I approached essentially the exact same way I did Day 6 part 1 (for one time through at least with that guard it ran fairly quickly so thought I would try that route again). Part 2 (once the new grid was prepped) I handled two different ways. For horizontal movement I treated it the same way as part 1, for vertical movement I decided to focus in on the objects in the path and used an additional nested iterative macro to do the checks for surrounding "big box" pieces and walls they might run into.
Main Workflow
P1 Macro
P2 Main Macro
P2 Check Macro
This took way longer than I hoped it would. I kept constantly crashing into bugs that were often trivial to fix, but difficult to find. I built a mechanism to capture all states of the map, and generated a video file to watch the robot on its route in the sample data to make sure nothing weird was happening... But that's all behind me now. No fancy algorithms, just good old fashioned brute force (with limited optimizations as well):
Move Robot Macro:
Helper macro to identify all vertically connected boxes that need to move as unit:
Finally, solved!
This is the one of the most difficult puzzle this year for me.
Part 1:
This is simple workflow.
Part 2:
Part 2 macro is too many tool and very complex workflow. Definitely the most complex workflow of the year. Horizontal direction algorithm is the same as part 1. But vertical direction is very messy.
The vertical algorithm consists of three parts. The first is an algorithm that extracts all objects in the direction of pushing the luggage from the starting point(@). The second identifies the luggage to be pushed. The third determines whether pushing will result in a collision with a wall.
Parts 1 and 2 are macros.
#1(Search object macro)
This macro extract the data as follows(blue box).
#2(Identify the luggage to push)
In the past, I missed the situation below. So, I create this macro. This macro is to solve that situation.
My first algorythm is not considered about orange blocks becase the X-axis push process was only performed once. I am using a iterative macro to group blocks repeatedly.
Day15P2 was one of the most challenging problems to solve in this year’s AoC.
In P1, there were 20,000 loops, and initially, history was maitained, which caused errors in Alteryx. The box positions were swapped using regular expressions, but the processing in P1 was somewhat redundant.
For P2, I gave up reusing P1 and decided to rebuild it from scratch. After considerable thought, I referred to @Tokimatsu 's workflow for inspiration. By representing only the left side of "O" and "#" as representative points without actually increasing the "O" and "#", significant simplification was achieved.
First, a mapping table was created in Excel by drawing a diagram of which range of cells would be affected when "@" or "O" moved. When "@" moved, the influence range of the pushed cells were calculated. If there was a "#" within the range, the move was canceled; if there was no "#", a macro updated the positions of "@" and "O".
P1 took about 10 minutes to execute, and P2 took about 8 minutes.
<P1 Macro>
<P2 Macro to check the pushed cell>
<P2 Main Macro>
