In this guide, you will learn how to create a timer with pause, unpause, and reset capabilities, as well as a beacon-based warning system and an idle auto extractor warning mechanism in ASTRONEER. These advanced automation techniques will help you streamline your gameplay and improve your efficiency. Let’s get started!
Preface
This guide doesn’t go over the basics of how sensors work or how to use them to trigger machines, there are plenty of other guides that cover the simple stuff. Most of what I’m doing here is at a lower level, using power switches and power sensors to build various circuits and link them together.
Pretty much everything I needed to know to build my crazy contraption came from this old Reddit post[redlib.pussthecat.org]. Some of the information is dated, but the core concepts remain intact. I mostly just updated some of the designs for the modern game and fit the pieces together to make them do what I want.
The Transistor
One of the other fundamental circuit components is the Transistor: a component that will let pulses go from the input (collector) to the output (emitter) depending on what the signal on the other input (base) is.
This is an incredibly useful component to have as it facilitates the implementation of conditional logic. So I looked over his auto arm implementation and remade it using power switches. Since power switches don’t consume any power, there’s also no need to use a QRTG. A single small battery with any charge in it at all will power the circuit forever since there’s nothing in the circuit that would drain the battery.
The second advantage of having no power draw is that we’re spared all the calculations on splitting power between components with splitters. A simple medium platform will adequately split the power signal and not only does it give 3 new power lines to the splitter’s 2, but it costs fewer resources to boot.
This is my redesign of the basic transistor, expanded out so it’s easy to see how it works.
In case you didn’t bother to read the original Reddit post, the power sensor on the left is to prevent the so called ‘faulty transistor’ issue, where toggling the base switch will trigger the emitter if the collector switch was left on.
This is the compressed version I like to use in my circuits.
Here’s an expanded side view to show the power cable connections with the base platform.
Now that you know what a transistor is, you ought to be able to understand the basic plan I have in mind to make a timer with pause and reset functionality.
Building a Timer
A quick disclaimer, the timer is not completely precise when using pause/resume since there’s no escaping the inability to pause a delay repeater that’s in progress. However this can be mitigated by using delay repeaters with very short cycle times.
Use a delay repeater to produce a constant tick at regular intervals (shorter cycles will make for a more accurate timer when paused/unpaused). Send the tick signal to the collector of a transistor. The emitter will increment the counter of the timer, while the base of the transistor becomes the pause/unpause button.
If you don’t need a reset function you could send the emitter of the transistor to a count repeater and be done with it. In my case though, I’ll need to reset the counter of the timer whenever an extractor produces a resource so count repeaters are out.
Instead I send the emitter of the transistor to a binary counter built out of power switches, so every time the transistor fires the counter increases by one. When the base of the transistor is toggled the emitter stops firing and the counter stops (ticks from ticker are blocked by the transistor, timer is paused). To reset the timer we simply clear the binary counter back to zero.
We can technically pick any number reachable by the counter for our timer expired signal by sending the corresponding digits through an and gate. For my purposes though, I will use the point where the counter ‘overflows’ back to zero. I will also send the timer expired signal through another transistor to ensure we don’t fire a signal during a timer reset operation. So a high level diagram would look something like this:
The Ticker
To start the ticker, simply toggle the collector switch manually. To pause or unpause the ticker toggle the base switch. Here’s a demo:
As mentioned earlier you can just hook this up to a count repeater if you don’t need reset functionality and the timer accuracy is better when choosing a lower delay for the delay repeater. I need the reset though, so my next component will be the binary counter.
The Binary Counter
Front view:
Compressed version:
All power connections are exactly as above, all I did was move all the switches and buttons onto medium storages.
If you’re wondering about the empty slots on the top they’re for ease of moving the machine. You can place the power sensors in the slots above the switches of the same column to make it easy to remember which sensor goes where.
I don’t know of any way to move the power sensors without breaking the power connections, but by keeping everything close together on the same platform we can at least prevent the signal connections from breaking. Then the medium storages can be placed on a rover and hauled off. This will be important for my intended usage of an idle auto extractor warning system, as auto extractors need to be moved around when resource deposits run dry.
The sensor that would normally connect to a fifth counter switch has no switch to connect to since there are no more switches in our counter. So when that sensor fires it means our counter just hit the highest possible number and is about to rollover back to zero. Picking that value for our timer timeout value will save us the trouble of trying to detect when a precise number has been reached by the counter, though I’m sure it could be done with logic gates.
Putting the Pieces Together
That’s how the counting mechanism works. That triggers a chain reaction when the reset button is pressed where all counter switches after the first one which is toggled on, will all be toggled on and then off. You can see this effect clearly in u/engin33rguy’s video[streamable.com].
The problem with this is that it will trigger the overflow sensor (the timer timeout value) every time the counter is reset. To prevent this I use another transistor. The overflow sensor will go to the collector of the transistor and the reset button will toggle the base switch. The base switch will be off during a reset and on during regular operation. Then the emitter of the transistor becomes our ‘timer has expired’ signal.
The transistor is built exactly the same way as with the ticker shown earlier including the power connections to the large T base platform which were conveniently not being used by the binary counter. I actually have the base switch and first power sensor of the transistor reversed here from where they were in the ticker but it really doesn’t matter as long as all the connections are there. I flip it around later for the sake of consistency.
To complete the timer we connect the emitter of the transistor from the ticker circuit to the increment button of the counter. Toggling the base switch in the ticker transistor will either stop or resume sending ticks to the increment button of the counter pausing and resuming the timer (with some loss of accuracy based on the cycle time of a tick). Hitting the reset button on the counter will set the count back to zero resetting the timer (similar potential loss of accuracy).
Demo:
Building an Idle Auto Extractor Notification System
We set the timer to a very long and generous timeout value (auto extractors are very slow after all). Every time the auto extractor produces a resource, the timer is reset to zero. Furthermore whenever the storage used by the auto extractor is filled we pause the timer and resume again when storage room becomes available.
If the timer is ever allowed to expire it means that the auto extractor has stopped producing resources, even though there’s still space available in its storage. In that case we emit some kind of warning so we know the extractor needs attention. I decided to build a circuit to activate a beacon to the red colour as my warning signal. So any time I see a red beacon on my radar I know an auto extractor has stopped mining as well as where to find it.
It would also be handy to have a warning reset button that switches off the beacon again and returns the whole system to its starting state. It would be even more handy to have the warning automatically reset if the auto extractor produces a resource after the warning was triggered. That might happen if you fail to provide the auto extractor with adequate power, causing it to slow down or stop and miss the timer deadline.
The Auto Extractor Circuit and a New Reset Button
To detect when the auto extractor produces a resource, I stick a dummy item in one of the two small slots of the extractor’s built in storage reducing its total capacity to one. I then combine a storage sensor set to ‘full or not full’ with a count 2 repeater by sticking one on top of the other.
Since there’s only one storage slot now, any time a resource is produced by the extractor it will trigger the storage sensor since storage is now full. When the auto arm removes the resource it will trigger the storage sensor again since storage is no longer full.
The count repeater gives us a convenient way to ignore one of the two signals (full or not full) so that we can respond only to one of them. For instance by sticking the sensor combination to the extractor while storage is full the signal we get when the auto arm removes the resource will get consumed by the count 2 repeater. The next time the extractor produces a resource it triggers the storage sensor again which triggers the count repeater which then acts as our ‘resource produced’ signal.
The auto arm moving resources from the extractor to the main storage area also needs to filter input so it doesn’t grab the dummy item.
Currently the counter reset button needs to be pressed twice before the counter can resume normal counting. Another interesting nuance is that if we toggle the reset button on and then off again on the next cycle it will only reset some but not all of the counter switches. This is due to the chain reaction we see where toggling off a counter switch toggles on the switch to the left of it. So we also need to give the counter time to zero out before we hit the reset button a second time.
A simple solution is a button repeater that will hit the reset button and at the same time a delay repeater. The delay repeater waits a few cycles so the counter can fully clear out before hitting the reset button again.
This is where I would explain the details of the automation cycle system and calculate the precise number of cycles we need to wait for the counter to clear if I held such knowledge. But who needs understanding when you’ve got trial and error? A delay of 2 3 4 cycles seems to work. In hind sight it might have something to do with the number of switches.
Since there was still room on the counter circuit, I stuck the button and delay repeaters on there right above the old reset button. It’s probably a more useful reset button than the old one anyhow. I also connected the pins for the storage sensors mentioned above.
A view of the auto extractor:
The Warning System
Unlike the counter reset mechanism there’s no pressing need for an extra delay this time. However I’ve heard rumours of problems being caused when you create an instant feedback loop by linking 2 button repeaters to each other. For that reason I decide to err on the side of caution and introduce a 1 cycle delay between beacon activations.
First we connect a button repeater to the collector of a transistor. Then we connect the emitter of the transistor to a beacon, a count repeater and a 1 cycle delay repeater that loops back to the collector switch. The count repeater keeps track of how many times we’ve activated the beacon and when we hit the right number, it toggles off the base switch of the transistor to stop the loop.
The circuit to deactivate the beacon is exactly the same only the count repeater is set to 6. To allow the beacon to be deactivated once it’s been activated we can connect the count repeater of the activation circuit to the base switch of the deactivation circuit and vice versa.
Demo:
Putting the Pieces Together
The final tweak is to make sure the timer is slow enough to give the extractor enough time to produce a resource before the timeout occurs. Up to now I’ve been using a relatively fast timer for demonstration purposes but the final timer needs to run slower.
There are 2 ways to make the timer slower. The first is to add more digits to the counter so it can count to a higher number. Instead of a 4 bit counter we might go with 6 or 7 bits. The other option is to make the ticker slower so that it takes longer to count to the highest value on the counter.
I went with the latter option for a few reasons. The first is that I’m not too concerned with the loss of accuracy that comes with a longer tick cycle. The timer will not be paused often in practice, probably no more than once in between resets. As long as we leave some buffer room in case a tick ends up running fast we should be fine.
Furthermore making a longer counter will mean adding more components to the machine, at least four for each new digit (counter switch, reset switch and 2 power sensors). Personally I think the machine is already large enough. The final reason is just a hunch that fewer ticks will be easier on frame rates. I’ve been using a 50 cycle tick by setting 2 delay repeaters to 25 cycles and stacking one on top of the other so the bottom one triggers the top one.
For demonstration purposes I’ll also remove the medium resource canister and use the T2 slot beneath it as the main storage of the extractor so we don’t have to wait forever to see it fill up.
Demo:
Moving the Beast
The primary issue with moving it is the second you pick up a power sensor the power connection will snap. You’ll also lose all the power connections to the base platforms as you move away from them.
To make it easier to remember how to reconnect the power lines I tried to follow some common conventions. The bottom most switch on all circuits is always connected to a constant power supply. Furthermore all transistors are connected in exactly the same way, see image at the start for a reminder. The counter connectors are also the same for every column. To remember which power sensor goes where there’s space provided in each circuit to store the corresponding power sensors while moving.
Another risk with moving the machine is accidentally breaking a signal connection. I’ve noticed sometimes a signal connection will not move with everything else when I pick up a medium storage. If that happens just put the storage back onto the platform and the signal connection will line up with where it was before so you can tell what it’s supposed to be connected to. Then you can redo that connection and it will usually move properly the next try.
A possible alternative to moving the machines around might be to keep them in one spot and simply extend the signal wires to wherever they’re needed. Chaining a signal through button repeaters and maxing out the available wire segments could allow you to make a really long connection. I’m not sure how well the game handles this though. Once again it might be safer to use delay repeaters set to 1 cycle rather than button repeaters.
Another possibility for long range signals might be the rail system. Activating a rail station or track segment calls the nearest car. The movement of that car could be detected by a circuit at the other end of the track. Feel free to post ideas and suggestions.
And that wraps up our share on ASTRONEER: Advanced Automation: How to build a timer with pause/reset and an idle auto extractor warning system. If you have any additional insights or tips to contribute, don’t hesitate to drop a comment below. For a more in-depth read, you can refer to the original article here by Ghost314, who deserves all the credit. Happy gaming!