Store Page
Microtopia
All Discussions Screenshots Artwork Broadcasts Videos Workshop News Guides Reviews

Microtopia

Store Page
Microtopia > Guides > Whompratt's Guides
Not enough ratings
Counters in Counters
By Whompratt
A brief example of how to sub-divide counted trails.
This is useful for limiting the number of ants in a trail, and also limiting a single ant within that trail to access a machine.
   
Award
Favorite
Favorited
Unfavorite
Created by
Whompratt
Offline
Category: Crafting, Gameplay Basics
Posted
Updated
21 Feb @ 5:09am
28 Feb @ 1:42am
2,721 Unique Visitors
8 Current Favorites
Guide Index
Overview
The Problem - Counting Sub-Networks 
The Solution - Logic Gates 
An Example - How I Use This 
Explaining the Behaviour 
Comments
The Problem - Counting Sub-Networks
Counter gates stop counting at other Counter gates. This presents a problem when trying to set up efficient production facilities.

In order to limit the number of ants working in a production centre, a Counter gate can be used at its entrance.
In order to stop multiple ants queuing for a single machine, another Counter gate set to 1 can be used to ensure ants ignore a given machine when in operation.

The problem here is that Counter gates stop counting at the next Counter gate.


If we close the loop, things start to break, and our secondary Counter gates become completely non-functional.


Using a Counter End gate after each gate stops the loops for the sub counters, but breaks the counting of the parent network.
The Solution - Logic Gates
The solution is another logical gate, preferably one you can guarantee will activate.
To do this, you need to chain the sections of trail as follows:

Production Line -> Counter (1) -> Haul -> Gate(s) -> Production Line

This causes the main Counter to count the entire network, including the sections after the sub-counters, and the sub-counters will count only the section before the additional gate(s).
Don't forget to add a Haul section between the entrance Counter gate and your additional logic gates, or your ants will simply pass by the machine.

In these screenshots, I use a single any Carry gate.



A 0 second Timer gate is the ideal choice, although these unlock later than the Carry gate, of which a pair set to any and not any can be used.

An Example - How I Use This
I use this system for my Fabric production network. Fabric requires more than one input, so an ant can leave the machine without carrying anything.

I prefer to create a physical separation between ants carrying a finished product and those that aren't.

Explaining the Behaviour
It's not entirely clear why the gates behave this way, and we'd need the developer to confirm, but I do have a theory as to what is happening, which I'll Sight Direction

I did have a section here explaining how I thought the behaviour worked, but I was wrong.
Fwiffo commented with some great information that I think is more informative, so to save you scrolling through comments, I've added it here.

Originally posted by Fwiffo:
It is pretty inconsistent in how the loops actually work. For instance, if you close the inner loop at an entrance of one of the internal gates, the loop doesn't work (however, chaining stockpile gates with counter gates works as a loop in my base so maybe only some of the gates are subject to condition? more testing required): https://steamproxy.net/sharedfiles/filedetails/?id=3435455050

However, if you change the last bit to connect to the loop at any other point, the entire loop starts working: https://steamproxy.net/sharedfiles/filedetails/?id=3435458200

Sometimes the loop seems to disconnect until you move the nodes at which point it connect properly again, so I'm not sure which is the bug - the fact that it works or the fact that it breaks. For instance, I thought that connecting 2 gates consecutively didn't work, but then I tried connecting them again in the exact same configuration and they worked perfectly.


What causes the special behavior to occur is when you have all 3 conditions satisfied:
1) Have a loop on the exit side of the gate (meaning the gate itself is not part of the loop)
2) All gates go in the same direction
3) The end of the loop is NOT at the entrance of one of the inner gates

At that point, the outer gate becomes able to see past the internal gates. Hard to say whether it's intended given how inconsistent this behavior is.
21 Comments
< >
jamiechi 18 Jun @ 6:52pm 
Thanks for this guide. I have been using the Carry gates and the Caste gates for this. I didn't think of using a Timer gate with a value of zero though.
Wierrat 11 Apr @ 4:20pm 
Interesting discussion! I'll add that from my observations, closing the counter loops is often conveniently done using an intersection, as the unit always chooses the forward path.
Opium 24 Mar @ 10:52pm 
Above is good for a group of production buildings with 1 worker slots going in and out, but same principle can be used for making "sub loops"... I used to have say 5 separate counters and parallel paths off my main loop going back to five separate groups of production, but have been moving more and more towards "sub loops".... So say, you have a big vertical main loop, then horizontal "sub loop" branches... then the five groups of production off the sub loop.

Same principles as above: for main counter to work, everything has to "connect back" to it if it goes through a nested counter... and you also need to loop back to a point after the main counter in order to count all the sub-counters. What's REALLY nice is you can use old gates as your connection back: old gate, old path to subloop, then a second old gate back to your main old path for the subloop (which in turn runs back to your main old path etc)
Nibbles 13 Mar @ 1:58pm 
I just use a splitter
Lickorice 8 Mar @ 5:43am 
Only five guides on this niche-ass game and this is the might be the only guide you'll ever need in playing it. Good job!
Fwiffo 28 Feb @ 2:01am 
Of course, go ahead.
Whompratt  [author] 28 Feb @ 1:38am 
@Fwiffo
Can I add your comments to the guide to replace my own?
Fwiffo 27 Feb @ 8:43pm 
To further illustrate how inconsistent looping is, here's another example: https://steamproxy.net/sharedfiles/filedetails/?id=3435476862

The build is symmetrical, but the outer gate can loop one side but not the other. I am currently in the process of debugging (ha!) it but there should be no reason for only one side to work.

update: apparently the solution was to remove and build the outside counter gate


I honestly wish they worked more consistently
Fwiffo 27 Feb @ 6:53pm 
[2/2]
However, if you change the last bit to connect to the loop at any other point, the entire loop starts working: https://steamproxy.net/sharedfiles/filedetails/?id=3435458200

Sometimes the loop seems to disconnect until you move the nodes at which point it connect properly again, so I'm not sure which is the bug - the fact that it works or the fact that it breaks. For instance, I thought that connecting 2 gates consecutively didn't work, but then I tried connecting them again in the exact same configuration and they worked perfectly.


What causes the special behavior to occur is when you have all 3 conditions satisfied:
1) Have a loop on the exit side of the gate (meaning the gate itself is not part of the loop)
2) All gates go in the same direction
3) The end of the loop is NOT at the entrance of one of the inner gates

At that point, the outer gate becomes able to see past the internal gates. Hard to say whether it's intended given how inconsistent this behavior is.
Fwiffo 27 Feb @ 6:53pm 
[1/2]
I don't think you got the principle down correctly.

For your last example, just reversing the timer gate isn't enough to make the counter gate to see through it, no matter the direction. Meaning it's not a matter of the counter gate being able to see through "backward" gates, even with a loop, so it only sees in the direction of the gate.

Screenshot illustrating the point: https://steamproxy.net/sharedfiles/filedetails/?id=3435453656

Moreover, it is pretty inconsistent in how the loops actually work. For instance, if you close the inner loop at an entrance of one of the internal gates, the loop doesn't work (however, chaining stockpile gates with counter gates works as a loop in my base so maybe only some of the gates are subject to condition? more testing required): https://steamproxy.net/sharedfiles/filedetails/?id=3435455050