Keep top level comments as only solutions, if you want to say something other than a solution put it in a new post. (replies to comments can be whatever)
You can send code in code blocks by using three backticks, the code, and then three backticks or use something such as https://topaz.github.io/paste/ if you prefer sending it through a URL
Is there a leaderboard for the community?: We have a programming.dev leaderboard with the info on how to join in this post: https://programming.dev/post/6631465
Every time I use Zig, I love the result, but I hate writing it. The language is just a little too inflexible for quick and dirty solutions to quickly try out an idea or debug print something useful, but once you're done and have a result, it feels quite complete.
Part 1 was fun, essentially a matter of mapping a grid and implementing a function to scan above and below bricks.
Was worried part 2 would either make the grid approach impossible (large numbers) or have combinatory complexity that would necessitate some super efficient dependency table that I don't know about. Luckily that wasn't the case! Phew.
For Part One I used a depth-first search which took too long for part two.
Part Two I created an adjacency list of the junction points while keeping track of the distance to the adjacent nodes at the same time. Then depth-first search through the adjacency list.
I sorted the bricks by their lower Z coordinate, then tried to move each of them downward, doing collision checks against all the others along the way. Once a level with collisions was found, I recorded each colliding brick as a supporter of the falling brick.
For part 1, I made another table of which other bricks each brick was supporting. Any bricks that weren't the sole support for any other bricks were counted as safe to disintegrate.
For part 2, I sorted the bricks again after applying gravity. For each brick, I included it in a set of bricks that would fall if it were removed, then checked the others further down the list to see if they had any non-falling supporters. Those that didn't would be added to the falling set.
Initially I was getting an answer for part 2 that was too high. I turned out that I was counting bricks that were on the ground as being unsupported, so some of them were getting included in the falling sets for their neighbors. Adding a z-level check fixed this.
Both of these have room for optimization, but non-debug builds run 0.5s and 1.0s respectively, so I didn't feel the need to write an octree implementation or anything.