
I'm kind of ambivalent about this - on the one hand, it's a really cool trick, and I love crazy big-footprint constructions to save on cycles on the other hand, it uses a non-replenishable supply of disposable arms, whereas I think a good solution ought to be able to work indefinitely. To get around the physics problems I had, one temporarily welds input blocks to the arm, then releases them by eviscerating the entire arm.


(Which raises the question: Is there any functional difference between running at max and running at one-unit-less-than-max? I mean, there's no way to avoid that one-block delay)īasically, it's transportation with rotating arms like I was trying to do earlier.
#INFINIFACTORY TRAINING ROUTINE 5 FULL#
I wonder if simply injecting that one-unit gap between blocks manually (with a simple drop or right-turn) before loading the hopper would sort out a few of the blockages which mean my devices often can't run at full tilt. That works to some extent, but I hadn't realised that because the following mechanisms require more movement, the extra delay between blocks that that introduces means that the next hopper - filling at full speed - will fill up more quickly than I had anticipated. This isn't insignificant one of my go-to construction approaches is to load a hopper directly from the source and use that to weld the first batches of blocks together. I think even at max input rate, while you might get a constant stream of blocks, the simple physics of movement is going to guarantee that you will have a one-block gap between blocks as soon as the block has to change direction (which includes dropping) I've been musing on this while trying to optimise the 'destroy the control console and keep the good monitors' level. However, the quickest way I could find to handle the thruster blocks was to push 6 of them at a time, which incurs a delay of 2 cycles for pushers to extend and retract.

At max input rate, the shuttles come in every 6 cycles, and the thruster parts come in every cycle, so you are evidently meant to destroy and replace the entirety of both thrusters - 6 thruster blocks to a shuttle. But I guess my alien overlords aren't the type to be terribly concerned over sustainable manufacturing or the deterioration of the environment.Īlso, if anyone is interested in collecting Steam IDs for leaderboard purposes, I'm florgle-floop.ĮDIT: So I just had a concrete example of this in Shuttle Maintenance. It feels rather messy and unbalanced compared to Spacechem, where a solution optimized for time could be designed without input blockages and with matched input/output flow rates that avoided accumulating garbage in a pipe somewhere. Then you end up with an excess of the other parts and you have to try to control their flow rate, and it seems like I still end up having to dump excess in a convenient pit. Unless there's a trick using a block I haven't unlocked yet, it seems like using any control structure other than a straight-ahead conveyor belt causes a momentary traffic jam in the stream. Click to expand.The input ratios are balanced, but what I find tricky is when you crank up the input rate to max, it seems to become impossible to avoid blockages when parts come in with no gap in between them.
