[MOD 0.17] Crafting Combinator

[Nexela]

Hey, its me again, i just wanted to ask, if There is a way to deactivate the virtual active provider chest of the combinator? After some testing, i realised that inserters and loaders are able to unload the combinator, after it has stoped the assembly machine and took out the remaining ingridients.

There's currently no way of doing that. It does seem like a good thing to add to my todo list though

Cheers TRK

Set the chest.active = false when your script places it.

[theRustyKnife]

Version 0.4.0 released.
Changes:
* Changed the way virtual recipes are generated which should increase compatibilty (thanks to [Nexela](https://github.com/theRustyKnife/Crafti ... tor/pull/4))
* Combinators are color coded now (by [Nexela](https://github.com/theRustyKnife/Crafti ... tor/pull/4))
+ Added automatic locale generation (thanks to [Nexela](https://github.com/theRustyKnife/Crafti ... tor/pull/4) again)
+ Added a subgroup for virtual recipes (once more by [Nexela](https://github.com/theRustyKnife/Crafti ... tor/pull/4))

[kann_]

Hey theRustyKnife
Thank you for your mod.

I like to build more complex combinator builds and I work on an automated crafting station with a single assembler. All in one factory or something...
I think this build will be a awesome.

The thing is it would make things much much easier, if you could make two changes to your mod. Or help me to make those changes myself, since I never made a mod myself.

• Output number of output item.

• Output active recipe.

The first suggestion should be obvious. I suggest to use an additional virtual signal with simply the number of output items, of course not the output item itself as a signal. This output should be added to the recipe combinator same as the time signal is already.
I would suggest to have the input combinator output the active recipe. This would make automation much easier, because I could wire several signals to the input combinator and remove every signal from the input that does not have all ingredients.

I have seen both changes being suggested by others as well. So I am not the only one

This would make automation so much easier... save probably 30 combinators from the build and a lot of pre-programming would not be necessary. I could send an gif of the current version, with half the functionalities implemented to convince you.

Thank you.

[kann_]

Ok I was able to figure it out myself.

In case someone is interested. Most changes are in the script/entities.lua file:

in RecipeCombinator:update I added:

Code: Select all

		local amount = 0
		for i, pro in pairs(recipe.products) do
			if pro.amount>0 then
				amount = pro.amount
				break
			elseif pro.amount_min>0 then
				amount = pro.amount_min
				break
			end
		end
		table.insert(params, {signal = {type = "virtual", name = "recipe-amount"}, count = math.floor(tonumber(amount)), index = 19})

in Craftig combinator:update I added:

Code: Select all

		if self.assembler.recipe then
			local params = {}
			for i, pro in pairs(self.assembler.recipe.products) do
				local r = 0
				if tonumber(pro.amount) % 1 > 0 then r = 1 end
				table.insert(params, {signal = {type = pro.type, name = pro.name}, count = math.floor(tonumber(pro.amount)) + r, index = i})
			end
			self.control_behavior.parameters = {enabled = true, parameters = params}
		end

In data.lua I added another virtual signal and changed the crafting combinator item_slot_count to 1
It could be interesting to remove the crafting signal from the recipe-selector, but it is not necessary.

[theRustyKnife]

Version 0.4.1 released.
Changes:
* Fixed a crash when loading with AAI Programmable Vehicles
* Fixed some virtual recipes would get the default icon when not necessary

[theRustyKnife]

Re: kann_
I'm sorry for the late reply, I didn't get notified for some reason...

Both of the points you mentioned have actually been on my todo list for some time, I just didn't have the time to put more work into it.

I'm actually planning to make a 'results' mode for the recipe combinator that will output the results, similarly to how it is now with ingredients. (To make sure recipes with multiple results are handled properly)

For reading the active recipe, I'm still trying to figure out what's the best way of implementing it. My current best solution is to allow the crafting combinator to also read the recipe. Obviously it would have to be possible to turn each of those functions on/off individually. Also copypasting the settings and making them stick when blueprinting would be necessary and that might cause some trouble...

Cheers TRK

PS: Feel free to post your creations using this mod here, I'm sure I'm not the only one who'd like to see them

[theRustyKnife]

Version 0.4.2 released.
Changes:
+ Added [Recycling Machines](https://mods.factorio.com/mods/DRY411S/ZRecycling) compatibility

[gridstop]

Hey, just wanted to say I discovered this mod today and it's fantastic for me. I'm working on a.... unique factory and this is a key part of it, in particular I was basically going to have to build the recipe combinator entirely by hand for almost every item in the game using constant & decider combinators.

One feature request... productivity modules get destroyed when switching to a recipe that doesn't allow them. Is there a way to check whether the thing you're about to set is not an intermediate and if so, move the productivity modules to the hidden active provider?

What would be REALLY great is if you could place the productivity ghosts when an intermediate is set so the bots install them again. Perhaps a second combinator that lets you send productivity/speed/efficiency signals themselves, and it attempts to install that ghost whenever possible.

[theRustyKnife]

Quote

Hey, just wanted to say I discovered this mod today and it's fantastic for me. I'm working on a.... unique factory and this is a key part of it, in particular I was basically going to have to build the recipe combinator entirely by hand for almost every item in the game using constant & decider combinators.

One feature request... productivity modules get destroyed when switching to a recipe that doesn't allow them. Is there a way to check whether the thing you're about to set is not an intermediate and if so, move the productivity modules to the hidden active provider?

What would be REALLY great is if you could place the productivity ghosts when an intermediate is set so the bots install them again. Perhaps a second combinator that lets you send productivity/speed/efficiency signals themselves, and it attempts to install that ghost whenever possible.

Hi, glad you're enjoying the mod.
You have a point with the modules, I'll see what I can do about it. It might be a good idea to let the player specify what and how many modules he wants to request too.
Cheers TRK

[gridstop]

Any thoughts on preventing input inserters from jamming?

At first, it's obvious that you don't want to remove the recipe until the input inserters hands are empty, so I set that up so it goes in to a 'cooldown' while the input inserters empty out, and then removes the recipe.

That fixes 95% of jams, though occasionally what happens is the recipe changes (or clears) right as the input inserters start to move, since it just finished a craft and now can accept more items. But that craft pushes the output chest over the limit I'm checking, so it stops all the input inserters. Since I have two or four inserters and they grabbed the same material initially, one jams. But then the other one is now disabled, so it can't load the other items to finish the craft that would free the first inserter, and the whole system comes to a halt.

I've tried adding the condition to not change the recipe when the inserters have something in their hands, but it feels like I'll still have a few tick window where the craft finishes and input inserters pick up the same item, jamming one. Unless I somehow split the components apart and use filter inserters, so no two inserters ever try to insert the same item and thus can never jam. Then I need some magical circuit that can split any combination of 1-6 signals into separate wires, which I'm not sure exists.

[gridstop]

I was trying to increase the update rate of the recipe combinator (don't actually need the crafting combinator to switch faster) and made the game crash by turning the update rate down to 6 ticks

EDIT: Another minor feature request, not sure how hard this would be: Add the rocket part as a signal that could be set on constant combinators, obviously you can't SET this recipe on an assembly machine, but then it would work with the recipe combinator in theory.

[gridstop]

For those interested in this kind of thing, here's a nano factory using the crafting combinator to build any item in the game automatically with a single assembler: viewtopic.php?f=193&t=42964

[theRustyKnife]

For those interested in this kind of thing, here's a nano factory using the crafting combinator to build any item in the game automatically with a single assembler: viewtopic.php?f=193&t=42964

That's a cool setup you've got there!

As for preventing the inserters from jamming, I could move the content of their hands into the overflow chest. That way they'll hopefully be able to start working on the new recipe right away.

Adding the rocket part makes sense. I'm not quite sure how to go about it tho. Maybe I could just hardcode it as a special case...

The refresh rate is not exactly intended to be changed if you're not starting a new game. It effects the data structure, which is currently only generated once when the mod is initialized. That said, decreasing it shouldn't actually crash the game as increasing it would, which sounds strange. Could you maybe send me the error you got?

Cheers TRK

[Nexela]

As for preventing the inserters from jamming, I could move the content of their hands into the overflow chest. That way they'll hopefully be able to start working on the new recipe right away.

I am all for this change!

[gridstop]

That's a cool setup you've got there!

As for preventing the inserters from jamming, I could move the content of their hands into the overflow chest. That way they'll hopefully be able to start working on the new recipe right away.

Adding the rocket part makes sense. I'm not quite sure how to go about it tho. Maybe I could just hardcode it as a special case...

The refresh rate is not exactly intended to be changed if you're not starting a new game. It effects the data structure, which is currently only generated once when the mod is initialized. That said, decreasing it shouldn't actually crash the game as increasing it would, which sounds strange. Could you maybe send me the error you got?

Cheers TRK

Thanks! I had a lot of fun building it.

I know there is a mod that has some special inserters that can fill a train without jamming. But even if that could be adapted it'd be nice if this mod could work with any inserter.

The rocket part, I mean honestly I can manually decode that one as well, check for some alternate signal and produce the results. That's just a slightly 'nice to have' but not nearly as important as something like the inserters.

It was a null/void object error on line ~100 I think in entities.lua if I recall, I think the get_assembler() bombs out when the assembler is removed. It was stuck (not setting the recipe) so I picked up the assembler and that's when it crashed, or when I rotated the crafting combinator. It's true the combinator was built when the mod had the update rate set to 60, then I saved, changed it to 6, and reloaded. I'll try totally disabling the mod, load game so the items are removed, changing the rate, and re-enabling it and see if it works OK like that. As you can imagine for my setup, being able to switch extremely fast on a single machine is valuable, and there's only one machine so the UPS hardly matters.

Thanks again!

EDIT: I was able to modify a blueprint string to make a combinator output the 'rocket-part' signal, and the crafting combinator works perfectly with it. So all you would have to do is add rocket-part to the 'crafting combinator recipes' tab that you added to the constant combinators.

[theRustyKnife]

I am all for this change!

I know there is a mod that has some special inserters that can fill a train without jamming. But even if that could be adapted it'd be nice if this mod could work with any inserter.

I have this working in my development version now, hopefully I'll be able to release it sometime this week. To give a bit of a progress status, I also implemented the product mode for recipe combinator, some more options for the crafting combinator and GUIs for all that stuff (I'm quite proud of how those turned out).

It was a null/void object error on line ~100 I think in entities.lua if I recall, I think the get_assembler() bombs out when the assembler is removed. It was stuck (not setting the recipe) so I picked up the assembler and that's when it crashed, or when I rotated the crafting combinator. It's true the combinator was built when the mod had the update rate set to 60, then I saved, changed it to 6, and reloaded. I'll try totally disabling the mod, load game so the items are removed, changing the rate, and re-enabling it and see if it works OK like that. As you can imagine for my setup, being able to switch extremely fast on a single machine is valuable, and there's only one machine so the UPS hardly matters.

Ok, that makes sense. I'll look into making it possible to change it on runtime in the next version (through a GUI maybe?).

EDIT: I was able to modify a blueprint string to make a combinator output the 'rocket-part' signal, and the crafting combinator works perfectly with it. So all you would have to do is add rocket-part to the 'crafting combinator recipes' tab that you added to the constant combinators.

Good to know, will certainly add this too then.

Cheers TRK

[gridstop]

Sounds great. I THINK I remember a friday facts where they talked about some improved/standardized API for doing mod configuration coming in 0.15. So for things like the tick rate (which I now know you can adjust before starting the map) I wouldn't worry about it for now at least.

EDIT: I meant to say the recipe combinator works perfectly with the rocket-part, not the crafting combinator (which obviously does nothing to a rocket silo).

[theRustyKnife]

Sounds great. I THINK I remember a friday facts where they talked about some improved/standardized API for doing mod configuration coming in 0.15. So for things like the tick rate (which I now know you can adjust before starting the map) I wouldn't worry about it for now at least.

I remember that too and it's going to be a nice addition to the API. However, 0.15 is probably still a ways off and I don't even know precisely how it's going to work so I think I'm going to rework that anyway (the new code actually supports it already so it's not going to be too hard)

EDIT: I meant to say the recipe combinator works perfectly with the rocket-part, not the crafting combinator (which obviously does nothing to a rocket silo).

I understood that. Haven't tried it yet tho.

Cheers TRK

[theRustyKnife]

Version 0.5.0 released.
Changes:
+ Added configuration GUIs for combinators
+ Added product mode to recipe combinator
+ Added an option to crafting combinator to read recipes from assemblers
+ Added settings copy/paste
+ Added an option to crafting combinator to empty inserters' hands to prevent jamming
+ Added a way to specify what type of chest to use for overflow items and modules
* Modules are now moved to overflow if they can't be used with the new recipe
* Half-finished crafting should now return the ingredients into overflow
* Crafting and recipe combinators now have seperate refresh rates specifiable in config (GUI coming later)
* Many minor changes

[gridstop]

Awesome! I just got the update, can't wait to try it. Will report back.

EDIT: One bug so far. If the machine has speed or efficiency modules in it, which should never need to be removed, it will actually duplicate the modules so you'll keep the modules in the machine, and get the copies in the provider chest. I guess you could make it only happen for productivity since the machine will destroy the internal ones, but that's not particularly mod friendly for other modules. Somehow detecting only the cases where the modules have actually been destroyed and not just removed by the player or bots or something seems like it could be tricky. Maybe there's a generic way to detect 'intermediate only' modules that would work across other mods that might have prod mk 4 or something.

I've seen the anti-jam working in practice, so that's awesome.

The new UI stuff is working well too I think.