- Build an Assembler 2
- Set the recipe to one that requires a fluid ingredient
- Use an upgrade planner to downgrade the assembler to an Assembler 1
- The recipe is cleared, because Assembler 1s don't support fluid ingredients
- Undo the upgrade
- The Assembler 2 is back, but the recipe remains blank
[2.0.20] Undoing downgrade of Assembler 2 to Assembler 1 does not restore recipe that requires fluid ingredient
[2.0.20] Undoing downgrade of Assembler 2 to Assembler 1 does not restore recipe that requires fluid ingredient
Re: Undoing downgrade of Assembler 2 to Assembler 1 does not restore recipe that requires fluid ingredient
This sounds like a duplicate of 121821
Re: Undoing downgrade of Assembler 2 to Assembler 1 does not restore recipe that requires fluid ingredient
Not a duplicate. The problem isn't that downgrading clears the recipe - that is expected and normal when the recipe in question requires a fluid ingredient, which Assembler 1s don't support. The problem is that undoing that downgrade with Ctrl-Z did not restore the recipe once it was an Assembler 2 again.
Re: Undoing downgrade of Assembler 2 to Assembler 1 does not restore recipe that requires fluid ingredient
Regardless of if its a duplicate or not, please provide a log file, or at least game version on which you observed the issue.
Re: Undoing downgrade of Assembler 2 to Assembler 1 does not restore recipe that requires fluid ingredient
Game version: 2.0.20-3
More detailed set of replication instructions:
More detailed set of replication instructions:
- Constructed a pair of Assembler 2s
- Set first one to make red belts, the other to make blue belts
- Using a default upgrade planner in right-click mode, marked both Assembler 2s for downgrade into Assembler 1s
- Bots from personal roboport applied the change
- First assembler recipe was still set to red belts, second one now blank. (This is expected and normal; Ass1 cannot make blue belts.)
- Using Ctrl-Z, ordered the downgrade to be undone
- Bots from personal roboport applied the change
- First assembler recipe was still set to red belts, second one is still blank.
Re: [2.0.20] Undoing downgrade of Assembler 2 to Assembler 1 does not restore recipe that requires fluid ingredient
@boskid: Do you still require more information?
Re: [2.0.20] Undoing downgrade of Assembler 2 to Assembler 1 does not restore recipe that requires fluid ingredient
I am going to mark this as Won't fix. The reason why this scenario fails is in essence the same one as with 118468 which is action done by robot having no access to undo item of a player. Original downgrade does not clear recipe so undo does not record need of restoring recipe and when robot then arrives to perform the downgrade, assembler clears the recipe as it is incompatible yet it is robot replacing the machine, not a player so this recipe change cannot be added anymore to the undo action.
This problem would go into even worst deep hole of corner cases: even if downgrade order would cause recipe to be cleared instantly (so it gets recorded in the undo action), the machine itself would get replaced by assembler-1 which is fine, but if you would undo the downgrade, then assembler-1 would be requested to upgrade to assembler-2 and at the same time a recipe change would be requested but this recipe cannot be applied to the assembler-1. This means that in order to fix the issue, we would have to completly get rid of the upgrade target of entities and instead fallback to always ordering old entity to be deconstructed and placing a configured ghost in its place.
This problem would go into even worst deep hole of corner cases: even if downgrade order would cause recipe to be cleared instantly (so it gets recorded in the undo action), the machine itself would get replaced by assembler-1 which is fine, but if you would undo the downgrade, then assembler-1 would be requested to upgrade to assembler-2 and at the same time a recipe change would be requested but this recipe cannot be applied to the assembler-1. This means that in order to fix the issue, we would have to completly get rid of the upgrade target of entities and instead fallback to always ordering old entity to be deconstructed and placing a configured ghost in its place.