Greetings! Super cool that someone is maintaining this mod, I've been using it since Rusty's original version in 0.14, that's my factory linked in the mod description :) I was thinking about picking up factorio again and building another nano factory in 1.1 or maybe even some modded games and had a couple small QoL/suggestions that have been long-term pain points for me.

The biggest problem is accurately counting output and accidental overproduction, since I have to wait for the inserters pulling from the machine to pulse, combined with latency of various logic necessary, and super fast craft speeds of just 3-4 ticks at the top end, it's impossible to craft exact amounts of things.

EDIT: I snipped out a long explanation, but I figured I'd rather be helpful, so I took a swing at it. I was able to setup the crafting combinator to latch the signal count when it switches to a recipe, and craft exactly that many times (by monitoring for wraps of assembler crafting_progress), after that it goes into the on_chest_full state with a limit reached message, and holds until the signal is removed or changed, and starts over.

So if you feed it '50 inserters' it'll craft exactly 50 inserters and then hold until you change recipe. At the moment there are a couple oddities:
1) It counts crafts, not products, so 50 belts will craft 50 times, and produce 100 belts, for example.
2) If you DID want to track production, it doesn't account for productivity, though this should be doable monitoring production_progress
3) Changing quantity on the fly doesn't do anything, I'm not sure that it should though.
4) CC has to observe the crafting progress wrap around, so the update rate must be higher than the fastest craft rate you want to monitor. Nothing wrong with this in the vanilla game, but could break down in mods where it crafts more than once per tick, or since the default update rate for CC is quite slow. So it'd need some warnings/explanation in the tooltip for the option.

I wrote a migration script for the variables, but I didn't add settings and stuff yet. If you're interested at all I can keep poking at and fork on github and do a PR, or just message you a git patch sometime.

Cheers!

Welcome back and thanks for your QoL suggestion

I am a little busy lately so I didn't get to read your long-version description. However, I would like to discuss your suggestion by breaking it into two concepts - "perfect count" and "craft latching"

Perfect count

First of all, have you tried disabling the craft-n-before-switch setting by setting it to zero? If the signal is removed from CC the recipe should be changed as soon as the CC updates. You just need to disable craft-n-before-switch and increase the update rate if you really need to achieve accurate crafting counts. You can go further by asking CC to not wait for output slot to clear and let it delete items.

Like you have mentioned, your solution to achieve perfect count will break under certain circumstances, so ultimately the update cycle will decide whether you can achieve perfect count or not.

My impression for having perfect count in Factorio is that it is usually very expensive, and rarely worth it. Most of the time you can still find ways to screw it up. For instance any brownout or blackout might affect the crafting rate, (or any bottleneck in the ingredients or inserter feeding speed, etc.). To address that the mod will have to update the tally more often to achieve perfect count, which is computationally expensive, while at the same time still not being able to ensure a perfect count scenario.

My opinion is that achieving perfect count in this mod is just not worth the cost for the extra computation involved.

1) Can you provide a more concrete use case for why this has to be solved by using mod script rather than just let machines overcraft?

Anyone else who thinks the functionality is worth the extra computational cost feel free to weigh in here.

Craft amount latching (need help naming this)

On the other hand, I like your idea of latching the amount of items. It is basically similar to craft-n-before-switch but in a different way (latch it in the beginning when signal appears instead of when signal disappears / displaced by another signal)

The implementation can share the same pattern as craft-n-before-switch. However I cannot implement perfect count for this functionality because of the arguments I provided earlier. I don't want to create room for more edge cases just to implement (or partially implement) perfect count.

For that, I am thinking of a timeout of 5s + crafting time needed for the latched amount. There is no tally to update, sticky duration is just the estimated time of completion based on the recipe crafting time + speed modifiers. Once the time is up, the CC will exit sticky mode, get the next signal, latch onto it, and go into sticky mode again.

How does that sound?

Hello!

The main reason is when computing large numbers of intermediate products in advance, the machine will consume intermediates that are needed later. Overproduction isn't actually the problem, over-consumption is. i.e. crafting red circuits, we make wires, and then green circuits... except we make too many greens, now later we'll block while crafting reds because there's not enough wires left. This is generally a unique problem to nano factories because I'm using only one assembler so I have to compute all intermediates to create.

The problem is not solvable with circuit logic because of latency. Craft speed even with just the in-machine modules gets down into just a few frames, so to detect the pulse from the inserters, invert it, subtract it from the counter, and have the CC detect the change and stop exceeds the craft time of 0.5s crafts like circuits and gears and sticks. I've experimented with this a LOT.

I think you're right that my perfect count solution in-mod is really specific and might not be broadly applicable enough to be worth adding, considering all the caveats. I can always maintain a patch/fork of it if I need to, without bothering anybody else.

One possible other option that would be more broadly applicable I think, would be if the CC could detect another virtual signal that told it to remove the modules on the fly, or even more generally, some new virtual signals that told it what type of module it should insert (and if none is present, remove them). This way I could calculate if I was crafting something with a very fast craft speed, and total time remaining was getting low, I could pull the modules and power off most of the beacons (since it's impossible to power them all off), which would get me down to a speed where the counter circuit and CC could keep up and stop in time.

I think I recall some other discussions where you mention difficulty in requesting specific modules because of the existence of modded modules. So just a simple 'inhibit all modules' or 'enable modules' virtual signal is probably all that could be easily done, and all I would need. Obviously if the signal is not present when the next craft starts it would re-insert per its normal priority logic from the chest.

I do nano-factories too because I do not find it fun to have to build malls every time I build an outpost in SE. I call it omnicrafter instead and I am not having issues with intermediate lockups (as long as I do not use the "craft-until-zero" mode).

I used to have problems with such build due to recipe flip-flopping caused by machine or inserter buffering items - I introduced the craft-n-before-switch sticky behaviour as an "intended latency" to solve that issue.

Check out my build and see if it addresses your issue. It has an infinity chest to provide iron and copper plates. The lower constant combinator states the intended amount to stock and the upper constant combinator states the priority.

0eNrNV1tuozAU3Ys/R6ECmkcbzU5GleXAJbEGbGSbZNIqC5iFzMZmJXNtEyCEpCStNO1HVL/OfZxzfc0bWeUVlIoLQ5ZvhCdSaLL88UY0XwuW2zmzL4EsCTdQkAkRrLAjpjUUq5yLdVCwZMMFBI/kMCFcpPCLLKPDy4SAMNxw8HhusKeiKlagcEODZC0aJkyQyGLFBTNSoZlSajwrhXUA8YLZw2xC9vhP/DBDMylXkPj16cRCGCVzuoIN23I8j4cynhtQo2JJZFmCChK2ysHGkMjKZiPuRDN5FwRydEhJwZMg4SqpuOlARQ1UfHhx00J4/7UFjOyPgrSbKI6jR9zpsdwQk3o4WFd6uYyvs3KezPCYzMglE1PJy4FEnBl6bAyleCS1W69xNu0a6TAWDzNWY1JcS3mTm4wrbehZ8rdcmQpnGo/8jgAwbJ94ryrMWuj+7FRRMuV8XZK/v//gWVmZsroLvdxTxy3NlCwoFwhDlkZVcBhPryuStQIQ/ZXpKfFeNPElmPCCLqatLhQ3mwKMFecIxsI+Y/NhxlrYzyFNg4WhA9xJ1CXzvpBvdxN3AzeziwwMEjayUmf3FFD4f+unXznfP79uMpbrWwpnfrFwnq9WynQcS/M7e5O/6D7YjNDtYIdcd7pHMAtvakUuM9dA4hEgF5piELUw04+2xS7Y7JbGOBtH5KLVoWHJz4ALDQqJuNISo5FX39F8IVOgMqOdC6pzFyhgKd0wf6cZ9E77JtHucItum0Vy/A4m4aLah+J+Gh93VMcdXtTul470uRMpQB4kG9DmSphNiY4ze6azycnyU2+86I0j2zbQ3oqpuuj6r+CwrTfFMoMPN9peNcvj3PXrJ+xTeMfTsnbUsLU7NeAMTZlhdk2DsUt+n003bR1CRzy5ZIeO7hiiZ3i0bhdG0iQHmwt34dsy0wlTKbVXhj6bzfKKp42MoCit67WSm2knqOMDtjOlS7BB15Bedv5FTLEmTNWac7FSvI94Tl9Byd6CwGLAGPDYjhvsYv4tb8NZVVmG7VbzV7AJHNRnFI0uxVMa3//A+RJ16RU+FHj7UcJFxgWuXSrO8L7afO4XW+Q1fDRHu0JVUMgtIMu+E0Nfc90GfXQbu1ZQ5swAab/j7Fu0VjgzAYrZBdTtzaft86bzLpf4snEddNn5MJ+QLTrn335P0XTxHC/mi3gax/PD4R9hn2rU

That being said, if you still think you need a "perfect count" behaviour for this mod, I am still open to the idea only if there is a better use case for it and/or a more elegant solution.

Regarding the extra virtual signal idea - I would like to point out that having extra information in the signals isn't going to work because of how the mod relies on signal cache. If it has to distill two types of information (recipe and module signal) out of the circuit network signals then the current signal cache won't work. Signal cache is integral to the mod to reduce the API calls required for circuit scanning.

I'll take a look at that blueprint and ponder on some ideas some more, probably won't have time to play for a while anyway. My model is having no stock, and always crafting precisely what is needed to produce # requested outputs, with no extra parts left over (other than input raw materials) which obviously makes it very sensitive to intermediate product counts. Just a different philosophy.

I agree, the actual swapping of modules isn't hard but when I looked at the signals.lua and the caching... ooh boy. Trying to snake a virtual signal through that to monitor would definitely be some real work. Best case it'd have to always be some negative number to make sure it didn't interfere with the cache, and new code to observe the value, which is going to make it clunky to use.

After some more random testing, I was comparing to the old Crafting Combinator, and the old version appears to be exactly one tick faster/lower latency than your fork. I guess some of the UPS optimization you did? Not sure if it's something in the input or if there's a logic branch that causes the stop/halt to take an extra cycle even with all the sticky stuff disabled. For now I'll have to stick with old CC since the math just works out that I can both hit max speed and yet disable enough beacons to count exactly.

I was really confused since I thought I had solved this problem in my last factory but then couldn't figure it out anymore, but I had switched to your fork since reinstalling and wasn't expecting it to have different latency.

That's odd, but it is a possibility. I have changed a lot of the original code in that regard.

Are you sure it is not a coincidental finding? That behaviour is not something I have expected. If you don't mind can you share your testing methodology for me to reproduce the said behaviour (of being exactly one tick slower)? I am interested to investigate the cause since it is not something intended.

Well my face is red on that one. The two builds were identical except when I removed the old CC, saved, changed mods, and loaded, I accidentally used a green wire instead of a red wire to attach from the register to the Xeraph branch CC. (the red wire is the feedback wire on the register). This caused it to take one extra cycle for the last pulse down to zero to pass through the counter register before it reached the CC. I was so careful to keep the builds identical and then forgot the wire color...

I still think long term it'd be nice if there was some way to either count crafts, or slow down assemblers by disabling modules or even just literally forcing the craft speed slower or something, to enable counting accurately with modded assemblers or modules. Since already the stock Assembler 3 w/ beacons is right on the edge of what is possible with a couple combinators counting and the CC at update rate 0, everything will fall apart immediately with mods.

Chasing perfect count by slowing down the machine is really something beyond the scope of this mod.

Crafting speed is hardcoded into the item recipe and machine prototype, so "literally forcing the craft speed slower" is not an option afaik.

thx 4 omnicrafter blueprint it is obvious now that i see it, i was missing it before i saw it

i have make 8-assembling machine surrounding 6x6 warehouse with circuits to take a list of desired products, iterate through the list, recursively calculate ingredients; if ingredients are ever in the warehouse build the products, probably without jamming too often

if recipe combinator took multiple inputs this would be easier, maybe, but this way a painful factorio for loop

why i play game where a for loop takes <...> minutes to write

why

it fun

In a recent FFF they explained that even in vanilla you can run into the limitation that assembler can only craft one cycle per tick and they fixed that. So now even scanning every tick would still get the product count wrong.

The simplest way to ensure perfect count though would be by counting the ingredients the crafting combinator inserts into the assembler. If you only put in 20 iron plates then you will get only 10 iron gear wheels. That is excluding productivity modules. Not sure what to do with them as their result is somewhat unpredictable. My idea would be to factor in the productivity rounded down. So a 30% productivity and you want 14 products would just run 11 cycles. That way you get a least 14 products but sometimes you get 15.

Note: This requires that you fill the chest of the crafting combinator with ingredients instead of feeding the assembler directly. But I think that is a reasonable compromise. If you want to insert directly into the assembler then do count the ingredients yourself.

So my suggestion would be an "feed exact ingreedients" switch instead of "run exact cycles" switch.