Improve chests replacement logic during force printing

[poisonousbeetle]

TL;DR

We need some better way to upgrade chests with an existing blueprint, not deconstructing them entirely before put a replacement chest.

What?

When I make my malls sometimes i use storage chest to store items that can be recycled or even for all the items instead of a regular passive provider chest. It is made for items recycle and to avoid overproduction, so every deconstructed item is returned to the production place and production is limited by a signal from that chest. Someone also prefer buffer chests for this purpose. Usually you want a mall to be functional before you have any bots/advanced chests, so you just replace them with regular chests. Later, after you researched bots, you want to replace all the chests with ones you setup in your blueprint. And if you used just passive provider chests, you are lucky, you can just reapply the same blueprint or apply an upgrade planner and they will be replaced easy. But if you used storage chests with a filter, your entire chest will be deleted and then a ghost with a replacement will be placed.

Why?

From a user perspective i can't see any good reason to delete a whole chest to replace it with another which contains additional properties such as filter/request. In my case with a mall if you just researched bots and want to replace all the chests you'll have to wait before drones will remove chests with tons of stuff, waste much time/energy for that. Or you have to recall which chests were actually storage/etc and replace them manually first, then reapply the blueprint. Each case is far from ideal.

How?

Not sure what was a rationale behind this, but if none was there I'd suggest to not remove a chest at all. If there is some, then maybe we could do replacement in some intelligent way, like remove from a storage chest just unfiltered items. Let's start a discussion.

references:
viewtopic.php?t=131712
viewtopic.php?t=131794

[boskid]

Rationale for linked topics is that a regular chest does not have logistic filters where it could store settings of the target entity, and so if a simple "upgrade" request was set to upgrade regular chest into a storage chest, then a storage chest would have no settings in it. That would mean if you force placed a blueprint with storage chest that was configured with a specific filter and an upgrade order was performed, then once the order is finished the entity would not have any filters set from your blueprint and as such you would need to restamp the blueprint again.

[poisonousbeetle]

So basically it is a more technical limitation and this design was chosen not because of you believe it is better but because it was much simpler to implement with existing constraints. Anyway, doesn't look as something impossible but it would improve quality of life.

[boskid]

Well, lets analyze this problem more thoroughly so you can see the problem as i see it:

When a super force blueprint building is used, it is expected that after all intermediate state is resolved (entities to be removed being removed, entities to be upgraded being upgraded, ghosts being built etc) you will get all the entities as in the blueprint with all the settings as in the blueprint. That means you will not have to restamp a blueprint and a subsequent super force building should result in no entity changes and no settings changes. There is always at least one way to achieve this exact behavior, and it is to order removal of the colliding entity and placing a ghost of the new entity. Entity in the ghost is of the correct type and as such can store all settings of the new entity.

Solution 1 was that since a container can be upgraded to a logistic container, an upgrade of entity was ordered. This creates a bug because original entity is unable to store settings of the target entity which resulted in 116130 (in some cases they may be completly different entities with no common parts). This behavior was changed to a solution 2.

Solution 2 is what there is currently here: since a container is unable to hold some parameters of a storage chest, a deconstruct+ghost is performed. When this is resolved all entities have correct settings and so it counts as a success. Players however seem to not like this behavior, and so we got some bug reports (131712, 131794).

Lets assume that current solution is indeed broken: a container must be ordered to upgrade to a storage chest, and settings must be preserved. Since upgrade will be resolved in the future game tick once a construction robot arrives, that means the settings for the new entity must be stored somewhere. This would require attaching a special "upgrade with settings" object to the entity being upgraded. This is technically doable, all the settings could be stored in an invisible entity copy that would be attached to the old entity, but this creates at least 2 new problems: first is that those new settings would be hidden, which means if you open an iron-chest before it is upgraded you would not see a storage chest's filter and so you could not interact with it. Now lets say you start changing settings of this iron-chest before it is fully upgraded, for example you change inventory bar to limit usable inventory down to 1 stack. This creates a second problem: when entity is finally upgraded by a construction robots, you get 2 sets of settings that now need to be merged: some settings from the old entity (inventory bar) and some settings from the new entity (storage chest filter). Deciding how to merge those settings would be a hive of bugs because there would be always some weird situation where either you expect new settings in the old entity to be picked (since they are newer than ones from blueprint) but settings from blueprint were selected, or the other way around where settings from blueprint should be selected since they were not present in the original entity but there was a special copy settings case that makes the settings to paste.

This solution would also create a lot of problems with modding api since mods would need to be given access to the new settings to be applied to the entity but it would have to be done in a way that does not allow other interactions with the entity. Lets say a mod would make a chest to be upgradeable to an inserter with custom vectors. While an upgrade is pending a mod would want to change pending inserter's custom vectors. So far the only way such settings can be provided is through an entity ghost, and look, current solution with deconstruct+ghost does exactly that, gives you a ghost with all the settings of the new entity.

There are in general 3 possible paths to choose here: solution 2 (that players dislike), solution 3 (that would create a lot of corner cases to handle) and a nuclear solution of removing super force blueprint building which would make everyone mad. In my opinion a solution 2 is the correct one and i am willing to ignore player's complaints about temporary state (items being expelled from the entity to be upgraded) since they are... temporary, and once construction robots are done with their stuff you end up with your blueprint placed as it was supposed to be.

Honestly i would be in favor of always solving super force blueprint building with a deconstruct+ghost. Lets say you are stamping some complex mall on top of a smelter stack. Just because some belts can be upgraded to a better tiers of belts would allow skipping upgrade of some entities, but that still makes it possible for some belts to align and you will end up with some iron-ore on an incorrect belt causing the stamped blueprint to not work properly. If all entities would be always deconstructed and then ghosts would be placed then all items from all belts would be removed and this trap would have been avoided. Look, this is just doable right now if you first deconstruct everything and then place a blueprint, no need for super force blueprint building. Maybe the nuclear solution would not be that bad after all?

[poisonousbeetle]

I see all the concerns, and mostly they are reasonable.

What about forceprinting over something completely different, I'd say usually you should not do that, you should use a decon planner anyway, because of there might left some inserters that will mix belts content or some belt which will screw up a neighbor belt. So imo force printing doesn't work as smooth as you imagine it should work. Eventually i would not consider this as a magic pill trying to replace a regular deconstruction planner + apply a blueprint. This kind of usage is limited to a simple use case like to get out of the way a roboport grid, and still a powerpole can block a connection between two inserters if they put items on the ground.

I think you shouldn't change current behavior too much, just don't put a deconstruction mark on the chest and that's it. Sure, if the current implementation implies you should have only "upgrade" state and "decon+ghost" state, then you'll have to play around to introduce "chest entity+ghost" state. So visually you will see it as an upgrade, when you open an item, it will be a ghost opened, if you apply an upgrade planner which "reverts" the type you just remove the ghost.