tonesjilo.blogg.se

Making counters in infinifactory
Making counters in infinifactory













making counters in infinifactory

In most cases where I've used "spare" input blocks to rotate things faster, it's been OK to destroy the "arm" immediately afterwards - e.g. Luckily I've yet to come across a scenario in which a fixed-pivot arm of input blocks would be worth it :) It usually only comes up when you're building two objects in parallel and you want to get them into the exit in consecutive cycles. In practice I don't run into this very often as I usually rotate objects into the exit one square higher than they need to be (so I can fit rotators underneath them), and the laser fires before the block starts moving downwards (and therefore there is no delay). So you have to fire it at the start of the next cycle and wait until the end of that cycle before it will be teleported away. On the other hand, if you rotate a block into a firing laser, the laser will fire before the block has finished rotating, and therefore miss it. So if you rotate an object into the exit, destroying an attached block with an eviscerator at the same time, it will teleport away at the end of that same cycle. The teleportation is done right at the end of each cycle. As evidence of this, if you pause the game mid-cycle you can see the "destruction" animation displaying at the location of the eviscerator even though the block is still nowhere near it! If you rotate a block into an eviscerator (or vice versa), the block will be destroyed while it is in the process of rotating - i.e. May I ask what you mean by parallel and sequential solutions? I'd love to see a subplot of the game where the contractor who submitted that design gets grilled on how extravagant it is. So, the arm activates only at the tenth piece, shaving 4 cycles off. Normally, the completed piece is pushed into the output zone by the next skip drive, but this left at delay at the end, leaving me at 228 cycles. My favorite part of the solution is the super extendable pusher arm with an inverted conveyor on it.

#Making counters in infinifactory how to#

I'm lucky that guy at the steam forum showed me how to do 'both' circuits, as I needed several of them to work out the timings of so many pieces, particularly in the belt area. There was no point to going any faster, since the three sections I assemble are so large that I can't get them out of the way fast enough. The great thing about this game though is that it never felt frustrating. Thanks! It was a bit of a nightmare-probably took me 12 hours off an on over a few days. This is especially true in the earliest levels. Original-block-only solutions can, indeed, often compete with the best, but the numbers in the current score table aren't as helpful to players using original blocks as original-block-only scores would be. Likewise, in area 4, other than my own solutions, I believe that all but one (4-3) use unavailable blocks. I believe that of the area 3 solutions currently listed in this table, all but one (the no-GRA 3-3 solution) use unavailable blocks. Their main value would be in areas 1 through 4. I agree that original-block-only scores are unnecessary in levels where all blocks have been unlocked. Even if many high scores use original blocks only, the mere possibility that they might use later-unlocked blocks makes the numbers less valuable to someone playing through the game. They mainly want to see the high scores, to evaluate their own. People who use high score tables don't necessarily want to study the solutions. Not everyone interested in best scores wishes to return to earlier levels using later-unlocked blocks, whereas everyone solves every level with original blocks. A small subset of them will attempt to beat the known best, succeed, and post in the high score thread. In my view, the main purpose of a high score table is for people who are playing the game to be able to evaluate their own best scores by comparing them against the known best.















Making counters in infinifactory