Been waiting for this one!

When I first saw that bundle of logic in the corner I thought you had done something cool and made an "are we ready to expand" analyzer. That wouldn't be too hard: A The final goal would be a "this is how many ingredients we're missing" signal (which you could display on a progress bar made from lamps): You get it by summing 1 for every less-than-zero signal on the "this is how many items we're waiting for" wire. B The "this is how many items we're waiting for" wire is the "sum of all items in chests" count plus "this is how many items we should have" signals (negative). If you want to ever look at it, you may want to filter it for only negative values. C The "this is how many items we should have" signals are essentially a "this is how many we can ever craft" (negative) signal, but slightly modified by adding "these items look uncraftable" (positive) signals (and _optionally_ feeding their sum through a filter that only allows negative signals through). D The "these items look uncraftable" (positive) signal wire is the sum of a "this is how many we can ever craft" (positive) signal wire and a "WE'VE SEEN THIS" (negative) signal wire, fed through a filter that lets only positive signals through. E The "WE'VE SEEN THIS" (negative) signal wire is a "we've seen this" (positive) signal, but multiplied by minus a million or so (which makes it "louder"). F And the "we've seen this" (positive) signal comes from a bog standard binary memory cell (output 1 for every signal larger than 0). This could be fed from the same wire that carries the sum of items in chests, but you'd probably want to instead get it from the inserters that input into the chests. Otherwise bots putting a manually crafted items into a filtered storage chest would mark that item as "craftable". G And finally, the "this is how many we can ever craft" (positive and negative) signals come from a constant combinator (or probably a set of them) and an arithmetic combinator multiplying it by -1. And if you already have the inputs for B and its sum (before filtering) on the same wire (right next to all the outserters), then you you can easily set them to work when [item they're providing] is smaller than zero. That will make the item counts work from a single constant combinator. [edit: Wait no, that wouldn't allow the inserter to grab the very first item ever produced. Unless you set them to work when the value is

Are you _asking_ to be suggested a simpler/smaller circuit logic? I wouldn't have done so, but in case it was to be understood that way: It's not simpler (to understand), but you can avoid the multiplication by 100, if you re-order the operations: Fist sum up how many bots are busy over the last 900 ticks; then divide by how many bots are available at the end of that 900 tick window (the number only changes right at the start of a window, and then only by 1 or 12 or whatever); then multiply by 100(percent) and divide by 900(ticks) in a single operation and then compare against the 90% target - or just check if it's higher than a target of 90*900/100=810; And then finally you multiply the "yes, I need a ... bot" signals by C. I personally would work with the "bots available" figure directly and check if it's lower than a target of 10% (or 10*900/100=90). I don't know if that could create problems for the duration while not all wires are in place though - then again, that's when you want to seed the system with a certain number of bots anyways. And I don't get why you have to take the tick duration of the averaging window _from the clock_ at 19:41. Just make the clock resetting combinator (at 15:22) compare against a "N" signal from a constant combinator, and then you can divide by the same "N" at the end.

About your first row of machines for intermediaries: Does the rest of the mall have the capacity to consume its full output? Because otherwise the intermediaries would be overbuilt (except for the few times when you grab intermediates for handcrafting). 10:00-ish: That belt feeding logistics bots into the roboport is not OCD compliant. I would have fed the bots in from the bottom. But _it'll work._ *_It's fine._* _I don't need to ask you to change that._ 10:48 Those explosive cannon shell machines look set up wrong. You can't input into the output slot of a machine, can you? 23:19 Leaving the beacons in the initial blueprint will beaconize the mall before beaconizing the module modules. I'd guess you'd probably want the priorities the other way around.

It would have been very interesting how you determined the needs in FactoryPlanner. pls consider this in future editions

Besides the whole excellent setup - the use of splitters and undergrounds in the basics / interrmediats section is stunning - after looking closely ist really nifty executed I learned a lot. But: With all due respect @MysticFish, the combinator setup is imho for over 90% of the users over the top. Isn't there (as you humbly mentioned) an easier and better understandable solution, digestible without being a math buff?

When's the next episode coming? ☺

You ever coming back to finish this ?

In order to build this mall you have to produce many of the entities (blue belts & underground, beacons, pipes e. g.) first - where do they come from?

Great series !! When are you gonna stop teasing and start building it? 😂

I let it run for many hours and the red and green circuits are still not backing up...