When I delete an assembler that is connected to a crafting combinator I get the following error:

"
The mod Crafting Combinator caused a non-recoverable error.
Please report this error to the mod author.

Error while running event crafting_combinator::on_tick (ID 0)
crafting_combinator/control.lua:106: attempt to index field 'assembler' (a nil value)
stack traceback:
crafting_combinator/control.lua:106: in function <crafting_combinator/control.lua:103>
"

Wow, this must have been there for ages... Thanks for reporting it - It'll be fixed in the next version.

It was the inserter clearing that was broken - it waits 60 ticks after the recipe changes to clear the inserters again (because reasons), but it didn't check if the assembler was still there by that point. So if you removed the assembler in that period it just crashed.

Thanks for the great mod and the continued maintenance

Just ran into the same issue as well; not sure how no one stumbled across it until now, it looks like it would be much more common... Was just testing the mod with bobs and set up a simple crusher-crafting combinator-constant combinator test. Set the recipe, made sure it worked, started deleting entities, deleted the constant combinator, missed the crafting combinator, deleted the crusher, got the error.
Would i be right in assuming you just need to check for nil and everything would work, or do you need to clean up the inserter list? This got me a bit into lua code so I am just a bit interested...
-
This is what i got so far in line 115 (added e.assembler ~= nil):
if e.entity.valid and e.assembler ~= nil and e.assembler.valid then e:empty_inserters(); end
-
Thanks for the mod by the way! Currently setting up ore manufacture (crystallizers... so many crystallizers) in seablock and wanted to not have to build 6x the size just to handle possible full throughput of all ores!

Basically, yeah. You could do that with just e.assembler instead of e.assembler ~= nil as nil evaluates to false, whereas an assembler entity (which is actually a table with some userdata magic) evaluates to true.

Also while I'm here, here's a bit of an update on the next version (with this fix): I finally got around to implementing some of my ideas for optimization, which worked out really well - in some scenarios, the new code runs in about 1% of the time the old did. This necessitated a couple changes to how the combinators behave though, which means this is probably gonna end up being a breaking update, despite my best efforts to write a decent migration.

The issues I can't really fix are blueprints, which will almost certainly not work between the versions, and the signal selection logic being slightly different with multiple signals of the same strength, which could potentially break existing setups that relied on the old behavior.

I decided to wait with the update until the weekend, when I'll have some time to think about it again, so expect to see a release then. I might also release an extra 0.14 version with just this fix for people who might want to put off the update to avoid breaking their setups... We'll see how it goes.