[0.17.74] Module request count not updated after upgrade planner changes assembly mahcine ghost

[n_slash_a]

What did you do?
I placed down a blueprint containing an assembly machine 3, which has 4 modules. In my current game, I do not yet have assembly machine 3 researched, so I used the upgrade planner to downgrade the machine 3 to machine 2, and then placed the machine 2 down. The upgrade planner was used so that the recipe of the assembly machine would be maintained (since placing a machine 2 down over a machine 3 ghost would clear the ghost).

What happened?
The Item Request Slot still contained 4 modules, rather than the maximum of 2 allowed by a machine 2. What I observe happening is that the 'extra' modules (number 3 and 4), will attempt to be delivered, and when they arrive at the machine, will be acknowledged and decrement the Item Request Slot, but fail to put into the machine. In the end, the Item Request Slot will be cleared, but there will be unnecessary trips by the bots to deliver modules that can't be accepted.

What did you expect to happen instead? It might be obvious to you, but do it anyway.
I expected the number of modules in the Item Request Slot to decrease from 4 to 2.

Steps to reproduce:
1) Place down a blueprint containing an assembly machine 3 with 4 modules (it does not matter if a recipe is set), but make sure it remains a ghost
2) Place an upgrade planner in your inventory
3) Open the upgrade planner, and add upgrading from assembly machine 3 to assembly machine 2
4) Upgrade plan the blueprint
5) Place down a machine 2 (by hand or bots)
6) Watch as the bots fulfill the Item Request Slot request

[Rseding91]

Thanks for the report. However, that's working as intended. It's an intended simplification and performance savings that the request count doesn't have to care if someone or something changes out the target.

[valneq]

What did you expect to happen instead? It might be obvious to you, but do it anyway.
I expected the number of modules in the Item Request Slot to decrease from 4 to 2.

The expectation is maybe reasonable, but what would you expect if you had 3 different types of modules in the four slots?
Which of them do you expect to be delivered, which of them to be ignored? Just keep the modules for the two left slots as requests? With the current behavior, the randomness of arrival times of the bots with the modules will determine which two modules you would end up with, right?

[n_slash_a]

Thanks for the report. However, that's working as intended. It's an intended simplification and performance savings that the request count doesn't have to care if someone or something changes out the target.

I understand, that is a reasonable expectation.

The expectation is maybe reasonable, but what would you expect if you had 3 different types of modules in the four slots?
Which of them do you expect to be delivered, which of them to be ignored? Just keep the modules for the two left slots as requests? With the current behavior, the randomness of arrival times of the bots with the modules will determine which two modules you would end up with, right?
My thought would be the left two to be kept. Yes, currently it is whichever two arrive first.

I'm okay with this being "won't fix", just glad yall already thought about it.