@Ronan You can still do with that with common classes. I did that today to create a modified BFS. Copied my shared one, then tweeked it. The util class is still a benefit though, since it's way easier to find. I don't need to go digging through solutions to find that class I want. Especially helpful when going from year to year.
I'd probably just add a new data structures js lacks, like a hashset with a custom hash function, and then a few functions to do things like floodfill, bfs etc
I'm playing Mineclone 5 (a Minecraft clone) single player via Minetest.
The second time I returned via the portal, this guy appeared (the first time he didn't appear). He doesn't attack me. If I right click on him, nothing happens.
Question: Who is this guy holding a gold sword who appeared ...
@murgatroid99 I calculate distances (including opening) between the start and each of the working valves and only "visit" each working valve once.
I'm going through all iterations instead of trusting Dijkstra to give be the optimal answer first, though
I do a simple BFS fill from each working valve over the entire graph to calculate those distances. All the pre-processing (input, parse names, parse connections, calculate distances) takes <20ms
for my input, every len(input) * len(pieces) chunk adds about 70k lines, but it takes 7³ chunks before the exact number of added rows loops
I thought 7³ to be meaningful because the board is 7 wide, but if I set the board to be 11 wide I get a period of len(input) * len(pieces) * unrelated prime number
also the actual period is MUCH MUCH smaller than that number
Well, it could avoid blocks that are there and fall very far, especially if it's a | piece
And that's also the reason why you can't just look at LCM(len(input), len(pieces)). A single piece could consume few or many moves depending on the current state of the board
Mastodon is cozy and quiet, you just have to survive the period where what all the new users have nothing meaningful to talk about other than mastodon and twitter
@MBraedley Because not every shape dropped uses the same number of moves. So n * len(pieces) pieces dropped can consume a number of moves that is not a multiple of either n or len(pieces)
@murgatroid99 but a cycle eventually sets up. That can only happen if the number of jets per cycle is an integer multiple of the len(input) and a multiple of len(pieces), and it's probably the LCM, but is definitely n*LCM
The point I'm making is that going through 5 shapes can consume the first e.g. 23 moves. And then the next 5 shapes can consume the next e.g. 27 moves. So, 5n pieces can consume your entire input exactly in one pass, and you don't need to iterate through 5 times to get to that point.
@MBraedley I didn't even notice that was what happened until we were having this discussion. I was tracking cycles in terms of number of pieces dropped
Forgot to account for when a rock is "nested" inside another rock... I thought I did, but it only works if the nested rock is air... meaning it's not nested at all
Every point of my rock checks to see if its being blocked before moving, and part of that check includes "am I looking at myself?"... but I'm just looping through the dimensions where the rock could be.
the + rock sees it can't moev since it's blocked by the L... except it's the L piece that's moving. + shouldn't be checking, but my loop is too naive,so yeha.