[MOD 0.17] Crafting Combinator

[Nightinggale]

When providing multiple signals to the crafting combinator, what is the formula to pick what to make?

Based on experimentation, it seems to be the same order as in the crafting menu. That is categories from left to right, top to bottom and in each category, it's also left to right, top to bottom. If so, can something like Osmosis Grouping be used to change the priority?

The reason I'm asking is because I have a setup where I have a wire with everything I want to build and the signal is removed once the threshold is reached. However it ended up being more complex than that because sometimes (particularly related to mods) the top priority requires an input of something with a lower priority, meaning if you run out, it gets stuck. This requires a much more complex signal generation to avoid getting stuck. I want to fix this, but I need to know if I'm heading in the right direction before I risk wasting lots of time on something, which will never work.

[Nightinggale]

Error while running event crafting_combinator::on_tick(ID 0)
Value outside of range in property tree at ROOT[0].count
stack traceback:
__crafting_combinator__/script/entities/RecipeCombinator.lua:80: in function 'update'
__crafting_combinator__/script/events.lua:56: in function 'run_update'
__crafting_combinator__/script/events.lua:66: in function <__crafting_combinator__/script/events.lua:59>

I got this twice now. It seems to show up completely at random unrelated to what I do, which makes sense considering it's on_tick. Quite annoying since it kills the game

I'm using combinators, which have been ordered by a blueprint and then placed by bots. Other than that I'm not sure I can provide useful information on what could have gone wrong.

[theRustyKnife]

When providing multiple signals to the crafting combinator, what is the formula to pick what to make?

The signals are checked in the order they are in the network. To my knowledge, that seems to be a separate thing from the crafting menu and such things, but happens to be ordered basically the same. However, as this seems to be a fairly 'internal' thing to the engine, I can't guarantee that this won't change. Hopefully it doesn't

Error while running event crafting_combinator::on_tick(ID 0)
Value outside of range in property tree at ROOT[0].count
stack traceback:
__crafting_combinator__/script/entities/RecipeCombinator.lua:80: in function 'update'
__crafting_combinator__/script/events.lua:56: in function 'run_update'
__crafting_combinator__/script/events.lua:66: in function <__crafting_combinator__/script/events.lua:59>

I got this twice now. It seems to show up completely at random unrelated to what I do, which makes sense considering it's on_tick. Quite annoying since it kills the game

I'm using combinators, which have been ordered by a blueprint and then placed by bots. Other than that I'm not sure I can provide useful information on what could have gone wrong.

Hm... That seems like a pretty strange error message. Is it possible that you have any mods that add recipes with crazy high ingredient or result amounts? That's at least what the message seems to try to say to me.
Maybe having your save will help troubleshoot this? Also, when did it start happening - after an update (which), somewhen between updates?
Let's get to the bottom of this

Cheers TRK

[theRustyKnife]

Oh. I think I see what the problem is - if the result of the multiplication of any recipe ingredient (or product when in product mode) by the coefficient you set in the GUI overflows from a 32bit integer, the game doesn't accept it as a valid input for constant combinators and instead of rounding it down or letting it overflow, it just throws an error at you.

I'm not entirely sure how to go about fixing it tho. There are basically three options:
- calculate a proper integer overflow (consistent with the game, but hardest to implement and compute)
- round down to 2147483647 (the middle route - fairly simple but doesn't break functionality entirely)
- ignore anything bigger than 2147483647 (easy and fast, but doesn't make much sense from gameplay perspective)

Of course, the solution would also have to be applied to underflow (tho that's probably rarely going to happen).
I think I'll give the first option a try and see how well it works. In the scope of the mod, the overhead of the calculations for the overflow should be entirely negligible. I mean, there are probably tons of other things that could be optimized to compensate for that...

Cheers TRK

[Nightinggale]

Based on that description I think I figured out what happened to my setup.

Each crafting+recipe combinator pair receives a signal from a memory, which is just a decider combinator. The loopback on that one goes through a circuit network switch, meaning it can be turned on and off. Another switch supplies the new signal and the two switches are set to be on with inverted conditions, meaning it always gets the input from just one. The input consist of signals with value 5 and the recipe combinator multiplies ingredients with input value.

Due to a not so lucky update in useful combinators yesterday, I had to disable and rebuild my timer for periodic update of production. My new timer is on 1 tick instead of one second. Apparently my setup works differently when it's on just one tick and both switches are on at the same time, meaning it just adds the new production request to the old one and even worse, it does so collectively for all memory blocks due to the way the switches work and the result is an exponential runaway of values. When I checked, it had 2.2k pipes as output from the decider combinator, which goes strait into the recipe combinator.

In other words I'm to blame for not having full control of the circuit timing. Still when something like that happens, the game should do something more clever than just show an error and go to main menu.

I think it would be fine to cap the calculation output if that's the easy and CPU friendly solution. Clearly nobody will intentionally request more than 2 billion of the same item, not even if it's to a series of assemblers.

[theRustyKnife]

Version 0.9.4 released.
Changes:
* Fixed that Bottleneck read mode would get disabled when not appropriate ([34](https://github.com/theRustyKnife/Crafti ... /issues/34))

[Nightinggale]

The signals are checked in the order they are in the network. To my knowledge, that seems to be a separate thing from the crafting menu and such things, but happens to be ordered basically the same. However, as this seems to be a fairly 'internal' thing to the engine, I can't guarantee that this won't change. Hopefully it doesn't

It's not always the same order as the crafting menu, but luckily there is a pattern to it. It seems that internally the list is sorted like this:

1. High to low value
2. Crafting list order

This means the crafting list is only used for signals, which happens to have the same value. This can be exploited if you are a bit creative.

Example:
Say you have a wire, which contains the signal for each item you want to make and the signals are always 1. You set it to produce gears and belts. The problem here is that belts have a higher priority than gears, meaning you have the risk of producing belts and get stuck due to lack of gears. Clearly the solution is to give higher priority to gears.

What I came up with (which works) is to set up two combinators with merged input and output. One multiplies by 5 while the other outputs 1 if input > 1. The decider combinator then has a constant combinator on the other wire, which outputs 1 gear. The combined output is then 5 belts and 6 gears, meaning gears will get priority.

The problem with this setup is if you use recipe combinators, which multiply by input. If you consider that to be a problem, you can always choose not to multiply by input and place a multiplier combinator on the output.

Why this turns out to be a great setup is that it allows ignoring priority when you build the circuit to decide what to build. This in turn allows building complex systems with hysteresis and stuff where all combinators use the each signal, meaning expanding to build more items can be as simple as adding signals in a constant combinator.

It can also be used to make one signal to feed multiple crafting combinators where each has different priorities, meaning each has a role (like without this mod) and they only switch to switching mode if their own production is no longer needed. This could benefit from having a higher threshold than the general signal. This would reduce the overhead from switching production often while it still allow all assemblers to switch according to needs and avoid idle ones.

I hope people will read this post as inspiration to make truly amazing automated assembly layouts

[Nightinggale]

I have a feature request. Currently when an assembler change recipe, everything in the assembler is placed in the crafting combinator for bots to pick up.

The change:
Once the current change recipe code finishes, loop through all input and output slots in the assembler and fill in as much as possible from the crafting combinator.

I noticed that changing production to gears dropped a bunch of iron plates in the crafting combinator and then production was stalled for a while because the input chest had run out. This is clearly highly inefficient, not to mention annoying.


Also it seems that there can be incompatibilities with other mods. For instance if you use Q's Cable-Making Mod, then the cable signal will not make cables. AAI Industries has two recipes for green circuit boards and crafting combinators can only pick the first.

I think the problem is that you use a signal and it picks a recipe for you. If you could have a menu or something (preferably global) where you can pick which recipe to use for each signal, mod incompatibility can be fixed by the player in that menu. It also solves the issue of controlling which recipe to use when multiple produce the same output.

[Nightinggale]

Error while running event crafting_combinator::on_tick (ID 0)
Index out of bounds: 21
stack traceback:
...afting_combinator__/script/entities/RecipeCombinator.lua:103: in function 'update'
__crafting_combinator__/script/events.lua:56: in function 'run_update'
__crafting_combinator__/script/events.lua:66: in function <__crafting_combinator__/script/events.lua:59>

Guide to trigger this:

1. Set up a constant combinator and a recipe combinator
2. Connect those two with a wire (only one wire needed for this)
3. Set the recipe combinator to "find recipes"
4. Set something "dangerous" in the constant combinator

Most of the time, it works great and can be really helpful. However certain items crash the game. So far the dangerous items are: gears, iron plates and copper wires.

Pure speculation on what goes on is that there are 20 output slots in the recipe combinator and it crashes whenever you pick an item, which is used in more than 20 recipes, hence writing to the non-existing 21st output slot.

Capping output to 20 slots is not really a significant limitation and I can live with that. Setting an overflow flag or something would be nice, but most importantly the game shouldn't be able to crash, regardless of how many recipes you add with multiple mods.

[Nightinggale]

Feature request: allow setting the recipe combinator refresh rate for each combinator rather than just a global, though they should default to a blank setting, which will make them use the global setting.

Long story short, I have a setup where two recipe combinators needs to be updated every 5th tick. This means I need to use CPU time on all recipe combinators even though the rest only change input max once every 7000 ticks.

A related question: how is the tick interval set? If it triggers on (global tick number % interval) == 0, does that mean that all recipe combinators will always trigger during the same tick, or can you end up with two combinators, which both triggers every 8th tick, but 4 ticks apart?

It would be nice if you can use update intervals to sync calculations, particularly if it is in sync with clock combinator.

[theRustyKnife]

Hi, I'm sorry for the late reply, but I'll try to address all the points you mention here.

I have a feature request. Currently when an assembler change recipe, everything in the assembler is placed in the crafting combinator for bots to pick up.

The change:
Once the current change recipe code finishes, loop through all input and output slots in the assembler and fill in as much as possible from the crafting combinator.

I noticed that changing production to gears dropped a bunch of iron plates in the crafting combinator and then production was stalled for a while because the input chest had run out. This is clearly highly inefficient, not to mention annoying.

This is certainly a good idea, shouldn't be *too* hard to implement either. I'll try to do this for the next release.

Also it seems that there can be incompatibilities with other mods. For instance if you use Q's Cable-Making Mod, then the cable signal will not make cables. AAI Industries has two recipes for green circuit boards and crafting combinators can only pick the first.

I think that the cables actually work as intended since the variations of the recipe are actually just different recipes, thus need to be addressed by the virtual signals. I could, of course, special-case this, but I don't feel like that's a good thing to do.
The issue with AAI was not entirely that the other circuit recipe wasn't registered, it just didn't get the proper icon and name. It was caused by 0.15's new recipe difficulty and is now fixed in my dev version. I'll probably wait with a release until I have more things done tho...

I think the problem is that you use a signal and it picks a recipe for you. If you could have a menu or something (preferably global) where you can pick which recipe to use for each signal, mod incompatibility can be fixed by the player in that menu. It also solves the issue of controlling which recipe to use when multiple produce the same output.

This might not be a bad idea, but I would have to redo a lot of things to get this to work. What I think might be a viable way of implementing this is that by default, the combinators behave same as do now, but there is an option to set it into the 'explicitly defined signals' mode. There are more important things that need to be done now tho...

quote

Error while running event crafting_combinator::on_tick (ID 0)
Index out of bounds: 21
stack traceback:
...afting_combinator__/script/entities/RecipeCombinator.lua:103: in function 'update'
__crafting_combinator__/script/events.lua:56: in function 'run_update'
__crafting_combinator__/script/events.lua:66: in function <__crafting_combinator__/script/events.lua:59>

Guide to trigger this:

1. Set up a constant combinator and a recipe combinator
2. Connect those two with a wire (only one wire needed for this)
3. Set the recipe combinator to "find recipes"
4. Set something "dangerous" in the constant combinator

Most of the time, it works great and can be really helpful. However certain items crash the game. So far the dangerous items are: gears, iron plates and copper wires.

Pure speculation on what goes on is that there are 20 output slots in the recipe combinator and it crashes whenever you pick an item, which is used in more than 20 recipes, hence writing to the non-existing 21st output slot.

Capping output to 20 slots is not really a significant limitation and I can live with that. Setting an overflow flag or something would be nice, but most importantly the game shouldn't be able to crash, regardless of how many recipes you add with multiple mods.

Your speculation sounds right, however, 'find recipes' should find recipes that produce a given item... I guess with lots of mods this can be more than 20? From my testing, it always worked fine, but I don't have too many mods in my testing Factorio install...
Anyway, I think I'll increase the number of slots a bit and make sure it doesn't crash on overflow for now.

Feature request: allow setting the recipe combinator refresh rate for each combinator rather than just a global, though they should default to a blank setting, which will make them use the global setting.

This sounds like a useful feature, maybe it'll be in some future release

A related question: how is the tick interval set? If it triggers on (global tick number % interval) == 0, does that mean that all recipe combinators will always trigger during the same tick, or can you end up with two combinators, which both triggers every 8th tick, but 4 ticks apart?

Currently the mod spreads the updates over different ticks. The code looks somewhat like this (if you're interested):

Code: Select all

for i=tick%interal, #combinators, interval do combinators[i]:update(); end

I'll try to get the two-tile recipe combinator into the next release, so stay tuned

Cheers TRK

[ichVII]

Hello,

I have a Feature request:
Is it possible to directly wire an assembly machine like in "dynamic Assemblers"? If yes, i would really like this, becouse my build is to tight to fit in These combinators. If no, then this should propably be a Feature request for the game devs, meaning including mod Support for wireable Assemblers.

[Nightinggale]

From what I gather, it should be possible to make a startup script, which loops all assemplers and clone them. The clones will then get wire attachment points. It could be useful to split input and output and possibly more than one output tile (one for each type of output) if it takes that path. Yeah it sounds like it could help in tight layouts. However while I wouldn't mind this addition, it's not on the top of my wishlist.

[theRustyKnife]

Hello,

I have a Feature request:
Is it possible to directly wire an assembly machine like in "dynamic Assemblers"? If yes, i would really like this, becouse my build is to tight to fit in These combinators. If no, then this should propably be a Feature request for the game devs, meaning including mod Support for wireable Assemblers.

From what I gather, it should be possible to make a startup script, which loops all assemplers and clone them. The clones will then get wire attachment points. It could be useful to split input and output and possibly more than one output tile (one for each type of output) if it takes that path. Yeah it sounds like it could help in tight layouts. However while I wouldn't mind this addition, it's not on the top of my wishlist.

I do like the idea and it is actually probably the way vanilla would have done it, but I don't think the mod's implementation would currently be better than what we have now. Of course, if assemblers were wireable, it would make things easier, but if we asked for that, it might just be better to suggest implementing this mod in vanilla. I'm not saying I'm opposed to that idea, but with all the signalling weirdness that's going on in this mod, I think they'd have to introduce some completely new system to make it vanilla-worthy and that would probably make it quite hard to implement.
If you want, you can try submitting some request, but I really don't know how well it's going catch on...

Assemblers can't have wire attachment points natively AFAIK, so a startup script wouldn't be very helpful. What I could do, is put the combinators 'inside' the machine they're attached to, and pretend they're the wire points, but I'm not entirely sure how well that would work either.

Anyway, there are currently many more important things to do, so this probably won't be done anytime soon anyway.

Cheers TRK

[MorphyNOR]

New here today, first time posting.
I absolutely love your mod, however I've ran into an "issue" with the Recipe Combinator.

I play with Bob's and Angels' mods + a lot of other mods too and while testing and creating blueprints for use in a save--game with Creative mods I've come into an issue where I setup the following:

Barreling Pump (Angels mods) <- input <- Check valve (Angels mods - to read content in pipe) <- Fluid source (Creative mods): Crude Oil
On the left side of the Check valve I have the recipe combinator setup to Find Recipes, on the right side (facing the Barreling pump) I have the Crafting combinator.
All this is wired as follows; green wire from check-valve to recipe combinator, then over to crafting combinator.

Now the problem; If I let the fluid source insert ie. crude oil into the pipe/check-valve, the recipe combinator gives the crafting combinator an instruction to unbarrel crude oil. Instead of setting it to fill crude oil barrels, which would be logical.

Am I missing something here? Is this a case of recipe sorting? Ie. whichever recipe happens to be before the other gets priority?

I tested to see if the reverse would be the same or different, so instead of check-valve I put an inserter+chest full of crude oil barrels (filled), it then proceeded to set the recipe to fill oil barrels... which is equally illogical.

[solntcev]

Recipe combinator returns recipe that produces item. So if you put fluid in it, it will output unbarreling or refining recipe.
You can make row of decider combinators to translate fluid signals to fill barrel signals.

When recipe combinator will have separate output you will be able to chain 2 to get barreling recipe from recipe items from unbarreling.

[Nightinggale]

I have run into a conflict with DP77s Better Basic Craftings. The issue is that assemblers will keep using the vanilla recipe even when something better shows up. Handcrafting on the other hand will use the improved recipes. I looked in the source code to see if this is fixable. I didn't fix the problem, but I started wondering about the code structure and possible optimization as well as making the mod easier to expand and configure.

The first thing I noticed is that there is a lot of looping to calculate something, which has been calculated before. More precisely matching up items, signals and recipes. This is a task, which really screams for a cache because when testing for say the signal yellow belt, the same recipe comes up every single time (unless modded otherwise).

First make two lists. One is ignored_signals, the other is signal_to_recipe.
On each update (which can be every Xth tick), do the following:

1. Read signals, though the loop should skip anything mentioned in ignored_signals
2. Return the signal with the highest value
3. Return {} if no signal is found
4. Check if signal is present in signal_to_recipe. If it is, return it (end search)
5. Some loop to find a recipe for the signal in question
6. If found, add [ signal ] = recipe to signal_to_recipe and return recipe
7. No valid recipe. Add signal to ignored_signals
8. goto 1

This will pretty much do as the code does now, except here there are two lists. If those are kept between ticks, then most of the time things will end after step 3 or 4. There is no need to make code to build the cache as it will happen over time on a need to know basis. no need to add stuff to the cache, which will never be used.

The problem with a cache is that it can be invalid. For instance if you invent something new and ignored_signals already has it listed. The answer to that is to just clear the lists. Do that on game load (don't need to save it in the first place) and gaining new tech. The easiest way to do that is to have one common cache, which all combinators will use. It would then be something like:

cache = list of [ assembler ] = {signal_to_recipe, ignored_signals}
Just clear cache and everything will start over. It has one cache for each type of assembler as not everything can handle all recipes. The assembler is naturally the one next to the crafting combinator.

Now that the actual recipe finding is called very rarely, it is allowed to take more time. This means if can make a list of recipes, which fits the criteria and then compare them for highest output/input and highest output/minute.

Another addon could be to add a window where you can specify if this signal, then use this recipe. This would be checked between 4 and 5 and it would have to check if the recipe is valid for the assembler in question, basically the checks from 5. Changing the list from the GUI would clear the cache as well.

Adding code this way would make the mod use significantly less CPU time and it would play nicer with other mods.


Another thing. It would be nice if you can set defaults for crafting combinators. I don't have bots invented and I keep forgetting to turn crafting combinators to act as chests. This leaves stuff in the combinators I can't get, which leads to another request: when changing chest type (inserter or provider), take the stuff already present and move it to the new type.

[theRustyKnife]

Version 0.9.5 released.
Changes:
* Added compatibility for [Omnicompression](https://mods.factorio.com/mods/EmperorZ ... ompression) and [Compressed Materials](https://mods.factorio.com/mods/Nexela/compressor) ([18161](https://mods.factorio.com/mods/theRusty ... sion/18161))
* Removed the flashing logistic network warning ([17387](https://mods.factorio.com/mods/theRusty ... sion/17387))
* Added compatibility for [New Game+](https://mods.factorio.com/mods/Bilka/NewGamePlus)

[Rouks]

Apparently there's a (nice) bug: when you select "Regular chest" for 'More excess items to" and "Mode excess modules to", I receive MORE items that I've put into the machine ^^
I'm getting infinite gems that way, actually

[Nightinggale]

Apparently there's a (nice) bug: when you select "Regular chest" for 'More excess items to" and "Mode excess modules to", I receive MORE items that I've put into the machine ^^
I'm getting infinite gems that way, actually

I noticed that with the previous version, but didn't report it because I have played around with the source code to add support for other mods (yes I will post it here once it's working as intended) and thought I broke it myself. My theory is that it can change the production from one recipe to the same, in which case items goes to the combinator and inserters just insert new stuff, leaving it undetected that something was removed. However so far I haven't actually figured out for sure what happens.

Btw if you change the inserter from provider chest to normal chest, it would be nice if the contents is moved as well. If you put something in the provider chest before inventing bots, it will get stuck there, which is bad considering provider chest is the default, hence it happens once in a while.