Factorio Forums

This is probably another non-bug,
but this behaviour seems to be a little annoyance like it used to be with losing science when having uneven lab timings or the newly patched crafting-reset-when-cancelling:

When you put e.g. 20 speed modules 1 in an assembler to craft speed modules 2, 4 are being subtracted for the processing with the other stuff.
Now when you reset the assembling machine recipe while it is still processing, you get the 16 remaining modules back with the other stuff, but 4 are lost in the process.

I think I know what you're saying.

In hand crafting, when you cancel a job in progress, you always get the stuff back.
In machine crafting, when you cancel a job in progress, you don't get the resources of the active job back.

Does that sum it up?

Yes, that's it.

I've never thought of it as a bug before, but it is an inconsistency.

It is not a bug, it is there by a design.
Consider the bonus production and productivity modules for example, it would be exploitable.

Productivity modules only work on cheap intermediate products, and you probably got more bonus resources before you cancelled the job. So it makes sense to not return items made with productivity modules.

But it is rather harsh to nerf all other recipes too.

Maybe there should be a button (or shift-click) to reset only when the current item is completed.
Rotating or mining the input inserter, and putting the item held by the insert back into the machine, are the parts being more annoying.

kovarex wrote:It is not a bug, it is there by a design.
Consider the bonus production and productivity modules for example, it would be exploitable.

I do not understand how it would be exploitable with production bonus, as it should just return the resources actually consumed and ignore the productivity bar progress, that progress should simply be lost with no compensation for the free item(s) you're now not going to get.

I also wouldn't care if there's no compensation for the productivity bar. I can't imagine how you would do that, and it's impossible to do it perfectly in any case, because you can't have fractional items. The bonus bar is just like the bar above it... when you cancel, you don't get compensation for the partially completed crafting, but you should still get the raw materials back. And the bonus bar doesn't consume any raw materials, so it ought to give you none back. While the main bar does consume, and so should give back. I hope that makes logical sense. Not getting these items back, is indeed an annoying inconsistency. The losses really add up over time. When I first noticed it, I thought it was a mistake / bug.

By the way, I think the way the productivity bar is displayed (and the way the productivity modules work) is brilliant. It should allow what I'm saying here to be more understandable.

It can be a "not a bug", but then why, if you pick up the assembling machine you get the full items in progress back and when you delete the recipe the items are lost?
This happen even without any module inserted, so it's not a productivity module related bug...
It happen even on assembling machine 1 and 2 long before you get modules tecnologies.
[I was publishing a new topic not sure if this is the same bug, but after reading it I've decided to add here my thoughts and experiences]

in both cases you get the items that were in the internal buffer back but if it was crafting something while you pick it up you lose the items it was using to craft

Smarty wrote:if it was crafting something while you pick it up you lose the items it was using to craft

No, when you pick it up you get the items it used for the current craft back and lose nothing. If you reset the recipe instead you lose these items. In my opinion it's not a bug, but an inconsistency.

Example: place down an assembler that crafts speed modules 1 and feed it 20 green and 20 red circuits, wait for it to start crafting.
If you now (during the first craft)

• pick the machine up: you get 20/20 back
• reset the recipe in the machine: you only get 15/15 back

kovarex wrote:Consider the bonus production and productivity modules for example, it would be exploitable.

I'm not sure how that would be exploitable. Bonus production is reset when you reset the recipe.

daniel34 wrote:

Smarty wrote:if it was crafting something while you pick it up you lose the items it was using to craft

No, when you pick it up you get the items it used for the current craft back and lose nothing. If you reset the recipe instead you lose these items. In my opinion it's not a bug, but an inconsistency.

Example: place down an assembler that crafts speed modules 1 and feed it 20 green and 20 red circuits, wait for it to start crafting.
If you now (during the first craft)

• pick the machine up: you get 20/20 back
• reset the recipe in the machine: you only get 15/15 back

Fixed for 0.15.

Rseding91 wrote:

daniel34 wrote:

Smarty wrote:if it was crafting something while you pick it up you lose the items it was using to craft

No, when you pick it up you get the items it used for the current craft back and lose nothing. If you reset the recipe instead you lose these items. In my opinion it's not a bug, but an inconsistency.

Example: place down an assembler that crafts speed modules 1 and feed it 20 green and 20 red circuits, wait for it to start crafting.
If you now (during the first craft)

• pick the machine up: you get 20/20 back
• reset the recipe in the machine: you only get 15/15 back

Fixed for 0.15.

Why this is then in "not a bug"? Or was this mistake?

Anyway I dont get why you have to lose ingredient when a job is in progress...

nuhll wrote:Why this is then in "not a bug"? Or was this mistake?

I think when they decide they don't want to fix a clear bug or oversight, then they call it "not a bug". But it looks like they're finally fixing it anyway. Abusing this "not a bug" phrase seems to be counter-productive, meaningless, and causes loss of information by reducing something to an oversimplification. Then it takes years longer to fix something than it really should have, which has an exponential cost in game popularity. ESPECIALLY since this is a bug which hurts new players more than anyone else, and such that they are unlikely to even know what's wrong, but they feel that something is wrong anyway, which hurts their opinions of the game.

I think "not a bug" means "working as intended", as in "we deliberately implemented it to work that way". But there might be a better implementation that is more logical/consistent. You could say that in this case, a fix is not fixing the bug - which never existed - but instead fixing the inconsistency.

In my mind (as a software dev) a bug is when code does something that wasn't intended, the word for deliberately implemented but illogical/inconsistent behaviour would be "issue". There may be no clear boundary between these two especially in the case of manifest behaviour but in this case it surely was a deliberate decision on whether to discard or refund items on recipe change and the code was likely working exactly as intended.

Note that in some cases software might be implemented deliberately in a slightly incorrect way in order to simplify it, thus reducing development time and possibility for bugs.