[MOD 0.17] Crafting Combinator

[theRustyKnife]

Version 0.10.1 released.
Changes:
- Updated for Factorio 0.17
- Recipe combinator is now a proper two-tile entity
- Crafting combinator now uses adjacent chest for item overflow
- Also a bunch of things that I don't remember
Bugfixes:
- Blueprinting should work now
- Again, other things that I don't remember / am too lazy to list here

[theRustyKnife]

Version 0.10.3 released.
Bugfixes:
- Fixed a crash when removing recipe combinator
- Fixed that crafting combinator wouldn't recognize a chest that existed before it was built in some cases
- Fixed a crash after removing an overflow chest
- Fixed recipes not being enabled if circuit network tech was researched before the mod was added

[theRustyKnife]

Version 0.10.4 released.
Changes:
- New nicer gui

[theRustyKnife]

Version 0.10.5 released.
Changes:
- An ultimately small tweak to the gui
Bugfixes:
- Fixed wrong locale key for read recipe checkbox

[gridstop]

Hey, really awesome to see this updated. I still absolutely love it and it adds so much potential to the game. I've spent probably hundreds of hours messing around with nano factories with this mod (and plan to again in 0.17 or 0.18 eventually)

Couple current things:
1) The new fluid anti-mixing system makes it even HARDER to flush pipes, because if you use for example a barrel filler controlled by a crafting combinator, it will hold a small amount of fluid in its internal fluid box, which keeps the whole fluid network locked to that. Then when you switch away from the barrel, it pushes that fluid out back into the network, keeping it locked forever.

So at a minimum, an option to destroy fluids in fluid boxes just before switching would be really nice.

2) I've noticed the CC can't set new recipes with incompatible fluids, which is fine, but right now it stays stuck in the old recipie (pipes contain acid and producing blue circuits, then change signal straight to concrete without going blank first, machine stays stuck at blue circuits instead of going blank).

If possible it would be good to destroy the fluid and change to no recipe in a single tick in this scenario, severing the connection to the fluid network so that the pipe network can then be flushed. Once the network is empty or on the new fluid, the recipe would then set correctly the next time the CC runs its processing.

3) The 'multiply by input count' option on the recipe combinator doesn't account for output product amounts. So if you put in say 5 yellow belt, it will output 5 gears and 5 plates, instead of 3 gears 3 plates. I did some hacking around on the old 0.16 version to make it mostly work by looking through the outputs for the thing being requested and dividing but I don't really know what I was doing in lua. Seemed to work in general without too much fuss.

4) Minor feature request would be some way to automatically switch back and forth between speed and prod modules. For instance, if I just put both sets of modules in the new module chest (since I can actually access it) just automatically put prod in if the recipe supports it, then put in any extra speed modules, then any extra efficiency, in that priority. I think fairly simple logic would cover 99% of cases.

[Nightinggale]

The new update is awesome. Now I can play 0.17 without constantly feeling that I lack CC. To me CC have become an essential part of Factorio.

3) The 'multiply by input count' option on the recipe combinator doesn't account for output product amounts. So if you put in say 5 yellow belt, it will output 5 gears and 5 plates, instead of 3 gears 3 plates. I did some hacking around on the old 0.16 version to make it mostly work by looking through the outputs for the thing being requested and dividing but I don't really know what I was doing in lua. Seemed to work in general without too much fuss.

Please make this optional. While it certainly helps to figure out resources needed to build a certain amount, at the same time it collides with any setup which wants to buffer input for a continuous production.

Idea: instead of just multiplying by a fixed number, how about allow multiplying by X/time? Time is the time it takes for the recipe to be produced and X is the constant number you type. If you say write 60, you will get input for one minute. If build time is 5 seconds it will multiply by 12 and if build time is 30 seconds it will multiply by 2. One possible usage for this would be to have a chest, which can feed an assember with an inserter. The combinators can request items by belts to be send to the chest, but say it can take up to 3 minutes for everything to arrive. If the recipe combinator wants 300 seconds of input materials, then it will still have around 2 minutes left when the items arrive, insuring that the assembler can be kept running at all time. This could also work with bot networks because particularly large bot networks tend to have a high delivery time.

Another thing I have been thinking of is the vanilla combinators. They flash a light when active, meaning they know if the inputs changed since last tick. I wonder if CC can somehow hook into that and update if input changed. This will make the combinators much more responsive and it will reduce CPU load in setups where inputs is often stable for at least a 4 digit amount of ticks. Of course this will require some simple bool check for input changed to work.

[gridstop]

Please make this optional. While it certainly helps to figure out resources needed to build a certain amount, at the same time it collides with any setup which wants to buffer input for a continuous production.

I guess I don't understand how it conflicts with anything? If you want to make 1000 yellow belt, you need 500 gears and 500 plates. If you are worried about continuous production & buffering you can use the craft speed and the assembly machine speed to figure out how many gears and plates you need in a given period of time, but that has absolutely nothing to do with the fact the ratio is 2:1 and not 1:1

Idea: instead of just multiplying by a fixed number, how about allow multiplying by X/time? Time is the time it takes for the recipe to be produced and X is the constant number you type. If you say write 60, you will get input for one minute. If build time is 5 seconds it will multiply by 12 and if build time is 30 seconds it will multiply by 2. One possible usage for this would be to have a chest, which can feed an assember with an inserter. The combinators can request items by belts to be send to the chest, but say it can take up to 3 minutes for everything to arrive. If the recipe combinator wants 300 seconds of input materials, then it will still have around 2 minutes left when the items arrive, insuring that the assembler can be kept running at all time. This could also work with bot networks because particularly large bot networks tend to have a high delivery time.

All of this is already possible with arithmetic combinators and the recipe time output of the recipe combinator along with the read craft speed output from the crafting combinator. I've been using it to set requests on requester chests since my first CC factory.

EDIT with howto: In this case what you really want is to not use the multiply by input materials mode. Feed the signal into the recipe combinator (set the time multiplier to 100), and get the speed from the machine, take materials per craft, multiply by assembly machine speed, then divide by recipe time. Gives you materials per second, multiply by whatever you want for seconds of materials.

eg with yellow assembler and green circuits:
(3 wire, 1 plate) * 125 Crafting Speed / 50 Crafting Time = (7 wires, 2 plate)
with speed modules
(3 wire, 1 plate) * 375 Crafting Speed / 50 Crafting Time = (22 wires, 7 plate)

Also, RustyKnife the 'read assembly machine speed' mode of the crafting combinator is currently bugged, it always reads 125 (for machine 3's) regardless of modules installed.

[theRustyKnife]

1) The new fluid anti-mixing system makes it even HARDER to flush pipes, because if you use for example a barrel filler controlled by a crafting combinator, it will hold a small amount of fluid in its internal fluid box, which keeps the whole fluid network locked to that. Then when you switch away from the barrel, it pushes that fluid out back into the network, keeping it locked forever.

So at a minimum, an option to destroy fluids in fluid boxes just before switching would be really nice.

2) I've noticed the CC can't set new recipes with incompatible fluids, which is fine, but right now it stays stuck in the old recipie (pipes contain acid and producing blue circuits, then change signal straight to concrete without going blank first, machine stays stuck at blue circuits instead of going blank).

If possible it would be good to destroy the fluid and change to no recipe in a single tick in this scenario, severing the connection to the fluid network so that the pipe network can then be flushed. Once the network is empty or on the new fluid, the recipe would then set correctly the next time the CC runs its processing.

I honestly didn't even think to check how the new fluid stuff affected this mod... Your suggestions are exactly what my thoughts on this would be . I don't see any big problems with this, so the next version should do pretty much what you described here.

4) Minor feature request would be some way to automatically switch back and forth between speed and prod modules. For instance, if I just put both sets of modules in the new module chest (since I can actually access it) just automatically put prod in if the recipe supports it, then put in any extra speed modules, then any extra efficiency, in that priority. I think fairly simple logic would cover 99% of cases.

I actually wanted to do something like this, but the logic for determining which modules to insert would actually be pretty convoluted because of the different tiers of modules (not to mention modded modules), so I ultimately decided not to implement it. It is still on my list of things to add in the future, so it may happen at some point.

3) The 'multiply by input count' option on the recipe combinator doesn't account for output product amounts. So if you put in say 5 yellow belt, it will output 5 gears and 5 plates, instead of 3 gears 3 plates. I did some hacking around on the old 0.16 version to make it mostly work by looking through the outputs for the thing being requested and dividing but I don't really know what I was doing in lua. Seemed to work in general without too much fuss.

I see why you'd want this, but I can't think of a good way to implement it without a million edge cases. In particular, what should happen if a recipe has more than one output? What happens when there is no output? What about recipes with output probabilities?
This is why I feel like it's better to leave it up to the player to build a system that suits their needs rather than trying to find some universal solution to these problems. So this is probably not happening.

Idea: instead of just multiplying by a fixed number, how about allow multiplying by X/time? Time is the time it takes for the recipe to be produced and X is the constant number you type. If you say write 60, you will get input for one minute. If build time is 5 seconds it will multiply by 12 and if build time is 30 seconds it will multiply by 2. One possible usage for this would be to have a chest, which can feed an assember with an inserter. The combinators can request items by belts to be send to the chest, but say it can take up to 3 minutes for everything to arrive. If the recipe combinator wants 300 seconds of input materials, then it will still have around 2 minutes left when the items arrive, insuring that the assembler can be kept running at all time. This could also work with bot networks because particularly large bot networks tend to have a high delivery time.

All of this is already possible with arithmetic combinators and the recipe time output of the recipe combinator along with the read craft speed output from the crafting combinator. I've been using it to set requests on requester chests since my first CC factory.

Basically this. It's already possible relatively easily.

Another thing I have been thinking of is the vanilla combinators. They flash a light when active, meaning they know if the inputs changed since last tick. I wonder if CC can somehow hook into that and update if input changed. This will make the combinators much more responsive and it will reduce CPU load in setups where inputs is often stable for at least a 4 digit amount of ticks. Of course this will require some simple bool check for input changed to work.

Unfortunately, there is no event fired for circuit network changes and it doesn't seem like something that'll ever be added (for good reasons). Trust me, I would love it if there was such a thing, but we'll just have to live with the way it works now. Also, the only thing it would really save performance on is finding the highest signal, since if that didn't change, the bulk of the code won't run anyway.

Also, RustyKnife the 'read assembly machine speed' mode of the crafting combinator is currently bugged, it always reads 125 (for machine 3's) regardless of modules installed.

I have kind of forgotten about this, but it's the way I designed it to work. Unless it was changed recently, there is no way to get the actual crafting speed of an assembler, other than calculating it manually based on the prototypes, which is a lot of cpu time for a fairly small gain. I could only do this when the recipe changes, which might make it manageable, but that would mean it won't respond to changes in modules between recipe changes, which I don't like. I actually think I made an api request for this, so something might have happened since then. I'll have another look at it, but no promises.

Thanks for all the feedback, I appreciate it. I don't really have much time to play factorio these days, so it would take me a while to even notice some of these issues .

[gridstop]

I see why you'd want this, but I can't think of a good way to implement it without a million edge cases. In particular, what should happen if a recipe has more than one output? What happens when there is no output? What about recipes with output probabilities?
This is why I feel like it's better to leave it up to the player to build a system that suits their needs rather than trying to find some universal solution to these problems. So this is probably not happening.

This is fair. It can be done by having a second recipe combinator reading products, grabbing what you want, seeing if it's above 1, and doing the division & rounding and such manually. It just significantly cuts down the number of steps (this is because in my current setup I have a huge chain of modules that calculates all sub-components simultaneously, which has a long latency to stabilize). Stack machines and processors are more interesting though anyway, so I might move back to that next time I build one.

I have kind of forgotten about this, but it's the way I designed it to work. Unless it was changed recently, there is no way to get the actual crafting speed of an assembler, other than calculating it manually based on the prototypes, which is a lot of cpu time for a fairly small gain. I could only do this when the recipe changes, which might make it manageable, but that would mean it won't respond to changes in modules between recipe changes, which I don't like. I actually think I made an api request for this, so something might have happened since then. I'll have another look at it, but no promises.

This isn't too much of an issue if the automatic module swapping isn't in there (though I suppose occasionally people power beacons on and off, which you'd really need a real API to get notified), since you can just hard code the machine speed for most calculations.

Thanks for all the feedback, I appreciate it. I don't really have much time to play factorio these days, so it would take me a while to even notice some of these issues .

You're most welcome. I don't have a lot of time either for megabases and the like but I still enjoy building interesting little machines like these. I noticed you figured out how to use the separate in & out 2x1 combinator prototype too, can't wait to look at the code for that and finally make a 'pick a signal' combinator or a 'pick the largest' combinator or something like that, should hugely simplify my designs.

[theRustyKnife]

Version 0.10.6 released.
Changes:
- Crafting combinator will set the machine to no recipe if the fluid inputs/outputs aren't compatible (viewtopic.php?f=190&t=34405&start=120#p422961)
- Assembler speed reading mode now accounts for modules and beacons (viewtopic.php?f=190&t=34405&start=120#p422961)

[gridstop]

The set-no-recipe first change works great. The speed detection is awesome too, even works when using a electric switch to power beacons on & off.

I did some experimenting with the fluid discard and added a GUI checkbox for 'discard fluids' and then in cc.lua move_items() right at the top before the check for discard items I just did:

Code: Select all

if self.settings.discard_fluids then		
	local count = #self.assembler.fluidbox
	for i=1, count do self.assembler.fluidbox[i]=nil end
end

I would've proposed a real diff/patch but I don't know how to make the migration work, since if a CC was created before this change it has no discard_fluids setting and the game crashes when you open them (you have to pick it up and put it back down). I figured it should be optional though since you may want to use this on barrel machines because you're actually trying to empty a pipe, but the normal assemblers & chem plants you'd rather not waste the materials especially if you change back to the same recipe later after clearing it.

[gridstop]

Also there's a crash when combined with Creative Mod. The 'find recipes' function dies when you feed it a fluid, presumably when it sees the weird infinite fluid recipe that the fluid sources use.

Error occurs in find_recipe in rc.lua, Unknown virtual-signal name: create-mod_free-fluid-sulfuric-acid (and -steam -water etc...etc...)

Not a huge deal since normally it's just for testing, but a minor annoyance.

[theRustyKnife]

I did some experimenting with the fluid discard and added a GUI checkbox for 'discard fluids' and then in cc.lua move_items() right at the top before the check for discard items I just did:

Code: Select all

if self.settings.discard_fluids then		
	local count = #self.assembler.fluidbox
	for i=1, count do self.assembler.fluidbox[i]=nil end
end

I might have missed something, but is this actually needed still? From my testing, it seems that just changing the recipe discards the fluids already. And since the recipe will be set to nothing when the fluids aren't compatible, all the fluidboxes will be cleared by the game. The only time they won't be cleared is when the recipes are compatible, in which case it isn't an issue, no?

Error occurs in find_recipe in rc.lua, Unknown virtual-signal name: create-mod_free-fluid-sulfuric-acid (and -steam -water etc...etc...)

That just sounds like creative mode adds its recipes in data-final-fixes and runs after crafting combinator, so it should be fixed by an optional dependency.

[gridstop]

I might have missed something, but is this actually needed still? From my testing, it seems that just changing the recipe discards the fluids already. And since the recipe will be set to nothing when the fluids aren't compatible, all the fluidboxes will be cleared by the game. The only time they won't be cleared is when the recipes are compatible, in which case it isn't an issue, no?

The fluids can't be incompatible when the machine is first transitioned from recipe->empty, because prior to that the fluid network was locked. Thus the instant it is set to nothing, the attached fluid box (pipe, tank) must be on the same fluid as the fluid box in the machine.

But when set to nothing the fluids aren't destroyed by the game, they are pushed back out to the input pipe/tank and then propagate backwards (if possible).This could actually cause weird mixing with CC in 0.16 because when changing a chem plant from a recipe with two water inputs to one with water & something, if the 'something' pipe was empty, it would push water out of the input fluid box into the empty input pipe, jamming it. This means you can no longer use a barreling machine to empty a pipe because you can't ever get rid of the last 0-49.9 fluid.

EDIT: In case we're talking about different scenarios here, simple test is barreler<-pipe->assembler. Start with some water in the pipe (making concrete) Change the assembler to processing units, and it goes blank and pushes all the water from its input fluid box out into the pipe. Then set the barreler to start filling water barrels, it empties the pipe but traps some water in the input fluid box. At this point the pipe is still locked to water but is empty. Then set the barreler to nothing, and it will push the last bit of water out into the pipe before it sets itself to nothing, leaving the pipe with water in it still. Repeat forever...

For reference for others using CC: If you actually want to change fluids around, you need to be able to completely empty/disconnect the pipe.
Options are:
1) Can no longer do any simple pump trickery, because the whole pump/tank network is connected, so it's always locked to one fluid.
2) Use a fluid tanker on a small rail chunk. This used to work and is what I did in 0.16. In theory it still could work because when the pumps disconnect the networks sever. However, in quick testing, I've routinely seen sub-networks get locked, and you have to randomly disconnect & reconnect pumps (even when everything is empty and there is no way fluid could actually go anywhere) and suddenly it shows truly empty.
3) Use barreling machines, which is what I did with CC on my first factory before rail tankers. Currently this doesn't work because of the above issue with removing the last <50 fluid from the network.

EDIT: Second ninja edit. I never brought this up before but I wonder if you have thoughts on it. For assembly machines the recipes seem to have default fluid box connection directions. Assembly machines always want to take input from the north and output to the south. You can rotate them but when CC changes it to something else and then back, it forgets the orientation. It would be handy if it remembered so you could fill & output in the same direction. Maybe when changing away from a fluid recipe, store the current direction, and restore it when setting a fluid recipe again. This is not a major deal just a curiosity.

[theRustyKnife]

But when set to nothing the fluids aren't destroyed by the game, they are pushed back out to the input pipe/tank and then propagate backwards (if possible).This could actually cause weird mixing with CC in 0.16 because when changing a chem plant from a recipe with two water inputs to one with water & something, if the 'something' pipe was empty, it would push water out of the input fluid box into the empty input pipe, jamming it. This means you can no longer use a barreling machine to empty a pipe because you can't ever get rid of the last 0-49.9 fluid.

Ok, I didn't notice that... It makes sense to clear the fluidboxes then. I'll make the update later today probably.

EDIT: Second ninja edit. I never brought this up before but I wonder if you have thoughts on it. For assembly machines the recipes seem to have default fluid box connection directions. Assembly machines always want to take input from the north and output to the south. You can rotate them but when CC changes it to something else and then back, it forgets the orientation. It would be handy if it remembered so you could fill & output in the same direction. Maybe when changing away from a fluid recipe, store the current direction, and restore it when setting a fluid recipe again. This is not a major deal just a curiosity.

I did notice this, but never put much thought into it. I guess I could see if I can do something about it. I dunno if it's possible to fill and empty in the same direction tho, because I think the input and output fluidboxes are actually two separate ones that are on opposite sides of the assembler. The whole assembler is then rotated, so the fluidboxes stay opposite each other. I didn't do any testing on this yet tho, so I may be completely wrong...

[gridstop]

Yeah the pushing inputs back out is something I think most people don't know about because when would they ever run into it, took me longer than I care to admit to figure out what was going wrong back in my first CC factory. I think that's why some people are annoyed for instance they can't put water pipe into the second oil input on a refinery while still doing basic oil processing since in theory it should be 'one way' and can't mix, but the reality is it's bi-directional.

The direction thing is really not a priority especially in vanilla since it's assemblers only ever output liquids when unbarreling, and you can just put one above the pipe and one below the pipe to do both directions. I just thought it was interesting because I couldn't figure out the mechanism.

[theRustyKnife]

Version 0.10.7 released.
Bugfixes:
- Fixed compatibility with Creative Mod (https://mods.factorio.com/mod/creative-mod) (viewtopic.php?f=190&t=34405&start=120#p424003)
Features:
- Add option to clear fluidboxes on recipe change (viewtopic.php?f=190&t=34405&start=120#p423990)

[gridstop]

Thanks! Erase fluids works perfectly and no issues with creative mod & fluid recipes now.

Of course now this means I pretty much have to make a new factory...

[theRustyKnife]

Version 0.10.8 released.
Bugfixes:
- Fixed crash when insta-deconstructing combinators with Creative Mod (https://mods.factorio.com/mod/creative-mod) (https://mods.factorio.com/mod/crafting_ ... 000be9856a)
- Fixed that crafting combinators wouldn't use each other's module chests for overflow sometimes

[theRustyKnife]

Version 0.10.9 released.
Bugfixes:
- Fixed that undoing contruction of crafting combinator wouldn't deconstruct the combinator properly (https://mods.factorio.com/mod/crafting_ ... 000d919fba)