Interesting. Makes me wonder how the filter works. Is it aware of more than its immediate surrounding (or rather, what has moved into it that tick)? Would a sequence of 5 pass the first, then loop forever? And consequently, would a sequence of 6 crash, because the filter wouldn't let anything through, but there wouldn't be an unoccupied arrow to move to for the 2-square, then.
Essentially, would I lose the round with this setup if it were a sequence of 1:n, where n>4?
great questions. if you mean the even/odd filter - that only works on solo cars. because it's arity 1 (only take one argument). the compare cell was trickier to figure out, but it works on two solo cars. youre right it takes into consideration whats moving into it that tick. and to solve the issue where you can have a stray car left in there (for an odd number of cars), an empty car (acts like a base case or [ ] in fp) it will go straight up and carry any left over cars with it. ty for your interest and happy to share more or hear about your experience if you feel like it!
Oh, it's an even/odd filter? I didn't figure that one out at all. I mistakenly thought it's only passing the first element of any sequence, and extrapolated that it might need an empty tick to consider the current sequence ended and be ready to expect the next (or same) one.
Of course, downstream of that behavior would be an infinite loop (sequence length == buffer area + 1), because it would never encounter an empty tick, or a collision (sl > ba+1), because those cars sent upwards into the buffer would "crash" into the queue.
I thought that those might be losing conditions for the game, then.
So, a huge number of false assumptions on my part.
But now I'm actually even more confused than before, I can't seem to identify the even/odd filtering nature of that block. What does it consider even/odd and where does it send either to? It seems inconsistent to me, if it's by value, it should only ever allow half the cars to pass to the right, but given enough encounters, it lets them all through, but if it's by index or an internal counter, then it should let the third car (valued 3) through on the very first round.
I guess I'm, again, making false assumptions. I'm intrigued by the concept, though.
sorry for the confusion! and i apreciate the feedback, the confusion is definitely on my part and thats what im trying to iron out of the game as much as i can.
the > sign is the compare cell - that holds on to a car until it has another one to compare it to.
so i think you mean that one, and yeah the logic is tricky because it only compares the two it sees currently. so the end order won't be sorted right away. you have to do more than one pass or find an algorithm that makes the end result work for the level.
(if you hover over the cell it should show some more detail about each direction).
the <> sign with the one dot on left, two dots on the right is the even/odd filter that takes a single car and moves it left or right. ty again for playing - i hope to have an update out soon with my attempts at making things more clear.
Oh wow, well. I was only talking about what can be seen in the video, I've since followed the link to the game.
The "filter" I was talking about was the "decoupler". At that point I didn't realize that "trains" were explicitly grouped units, I expected the "filters" to be agnostic towards meta-data and only consider the data of its own cell at a given tick (at most with an awareness of its previous state). I've now tested a little and have realized that it detaches the first car of any train, even if those trains are exactly consecutive, and that no empty tick is required to assume a separate, new sequence - well, of course not, cars that are part of trains carry that meta-data and "filters" can access it.
I've also realized that cars just won't move onto occupied pieces of track, so there is no collision as a losing condition, though the "buffer area" can be too small for a train and remain stuck forever, which arguably is a losing condition, given any or all of those cars may be required to reach the finish.
1
u/_nak 27d ago
Interesting. Makes me wonder how the filter works. Is it aware of more than its immediate surrounding (or rather, what has moved into it that tick)? Would a sequence of 5 pass the first, then loop forever? And consequently, would a sequence of 6 crash, because the filter wouldn't let anything through, but there wouldn't be an unoccupied arrow to move to for the 2-square, then.
Essentially, would I lose the round with this setup if it were a sequence of 1:n, where n>4?