[boskid][2.0.42] Inserter loses assigned pickup_target when it is a proxy-container whose inventory is invalid temporar

[noodlebox]

1. What did you do?
I have inserters picking up and/or dropping items into proxy-containers in a mod I'm making. `pickup_target`s and `drop_target`s refer to proxy containers to implement controlled access to specific inventories and entities based on player configuration or circuit logic at runtime. This explicit assignment is necessary in my use case because one or more of these container entities may share the same tile with others depending on inserter placement, or they may overlap other entities that are valid as targets otherwise.

My usage seems to be very similar to the case here, which suffered from issues whose root cause may be related: viewtopic.php?p=665914

2. What happened?
Whenever the proxy container's proxy target (entity or inventory) settings temporarily refer to a non-existent inventory, any connected inserters waiting for items from it have their `pickup_target` property set to nil. This is problematic in my case because this usually means inserters immediately re-attach themselves to new targets nearby. They resume "working" with unintended item movement between entities or inventories they were not expected to access while losing access to the inventories they were intended for.

Worse, the loss of property data on one entity (or possibly several) happens as a result of a property change on another. Even if the code touching the entity that could cause the potential breakage wants to be careful, tracking down affected entities can be tricky as their relationship is defined in the other direction (from inserter to container), not to mention that the property storing that reference is the one whose value is lost. Even if located, their positioning may still leave the original connections ambiguous. Any hope of maintaining or restoring a valid and consistent state requires more proactive and redundant bookkeeping (assuming careful cooperation among any of their users).

pickup_target becoming nil, then restoring itself.

Screenshot from 2025-03-25 21-30-44.png (376.65 KiB) Viewed 519 times

Same sequence of events, except a car is parked too closely this time.

Screenshot from 2025-03-25 21-31-36.png (777.43 KiB) Viewed 519 times

3. What did you expect to happen instead? It might be obvious to you, but do it anyway!
I expected the inserter to wait patiently for usable items to become available again from its connected target, as they typically do in similar situations. Once unblocked, I expected it to resume normal operation just as before the interruption. I expected its configuration to persist during this period, as the entity it referenced did not move from its position, remaining alive and valid otherwise.

On most entities that don't move, there is a reasonable expectation of stability in their relationships to each other, with any exceptions detectable through events. A similarly configured `drop_target` works as I expect so far. It's only the `pickup_target` that loses its value when unlucky. There is some strange magic hiding underneath pickup logic.

[Rseding91]

Thanks for the report however this is working correctly. Inserters will always clear a pickup target if it no longer has any valid inventory to extract from.

[noodlebox]

Inserters will always clear a pickup target if it no longer has any valid inventory to extract from.

Thank you, though if not a bug, the chosen behavior is surprising. Blocking on an input machine that temporarily switches to a state of being not ready is an expected pattern. If other configuration details were similarly forgotten just because an inserter had to wait for a moment, there would be chaos.

[Rseding91]

Inserters will always clear a pickup target if it no longer has any valid inventory to extract from.

Thank you, though if not a bug, the chosen behavior is surprising. Blocking on an input machine that temporarily switches to a state of being not ready is an expected pattern. If other configuration details were similarly forgotten just because an inserter had to wait for a moment, there would be chaos.

Machines that temporarily say "I don't have any items to provide in these inventories" is different from a machine saying "I have no inventories to provide".

[robot256]

Since your mod is already setting explicit targets for the inserters, it should be trivial to re-assign them when the proxy targets change. Or better still, if possible, give the proxy containers fixed targets and change the inventory selection by altering just the inserter targets.

[noodlebox]

Inserters will always clear a pickup target if it no longer has any valid inventory to extract from.

Thank you, though if not a bug, the chosen behavior is surprising. Blocking on an input machine that temporarily switches to a state of being not ready is an expected pattern. If other configuration details were similarly forgotten just because an inserter had to wait for a moment, there would be chaos.

Machines that temporarily say "I don't have any items to provide in these inventories" is different from a machine saying "I have no inventories to provide".

I understand they're different things to say. What I don't agree with is the assumption that one of these is temporary while the other is definitely not. If that were true, then the chest would either behave like a normal predictable chest (always valid), or like a normal predictable brick (always invalid). Neither of these cases are improved by breaking interaction in a surprising way for anyone who reasonably assumes that a dynamically configured chest that has just changed might change again in the future.

Since your mod is already setting explicit targets for the inserters, it should be trivial to re-assign them when the proxy targets change. Or better still, if possible, give the proxy containers fixed targets and change the inventory selection by altering just the inserter targets.

Yes, there are ways to work around it, like I mentioned. I have something that mostly works for my case, but it just seems less than ideal to require a mod using these new systems in a pretty mild way to now cooperatively re-implement base game interactions between mostly standard entities, or else stumble into brand new behaviors that are almost definitely not what you want.

I know it's a new way to interact with a very complex system and there are going to be kinks and weird implementation details it reveals. I'm just hoping this is seen as one of those kinks worth working out.

[robot256]

Does the inserter find a new target if the proxy is unlinked and relinked in the same tick/event handler? The biggest hack would be linking "disabled" proxies to empty/full/0-slot script inventories to prevent inserters from getting distracted.

Seems like what you need is the ability to set a disconnected proxy to the "disabled" or "empty" state like machines can be, regardless of what inventory they are connected to (if any). That way you can prevent any attached inserters from retargeting without needing to interact with each of them individually. When the proxy is enabled, it would pass through the host inventory's status as it currently does.

I think that would be a reasonable and useful interface request. The current behavior makes sense in the context of the existing interface.

[noodlebox]

Does the inserter find a new target if the proxy is unlinked and relinked in the same tick/event handler?

No, it takes at least a single tick spent on the pickup side in this state. It keeps its target otherwise, which is possible if it's in motion and the link is restored before it reaches the pickup side again (or if it's waiting on the drop side).

The biggest hack would be linking "disabled" proxies to empty/full/0-slot script inventories to prevent inserters from getting distracted.

This is actually what has been doing the best for me so far. I think it hints at a cleaner possible solution, but the workaround seems to keep inserter behavior at least functionally correct without most of the added jank, with just some extra overhead to keep things consistent when proxy targets go away, as well as the invisible 0-slot chests hiding in my maps to hold it all together.

Seems like what you need is the ability to set a disconnected proxy to the "disabled" or "empty" state like machines can be, regardless of what inventory they are connected to (if any). That way you can prevent any attached inserters from retargeting without needing to interact with each of them individually. When the proxy is enabled, it would pass through the host inventory's status as it currently does.

I think that would be a reasonable and useful interface request. The current behavior makes sense in the context of the existing interface.

I agree, that kind of control over how a machine makes itself available to inserters (or not) at runtime could be very powerful if forceable in either direction, making where and how the side effects of implementation details show up like this much less of a concern. I'll make my case over there if I feel the need after I see how this and some other proxy uses I'd like to try go.

[boskid]

I looked at this a little bit closer and noticed that inserters were not fully respecting what pickup target declares. Inserter should check if pickup target is valid pickup target and remain connected to it as long as it is valid, however it instead used a different check, a "has output inventories" which in case of proxy container could fail in some cases. For 2.0.44 i changed inserter logic to not check for lack of output inventories but to check if entity is or is not a valid pickup target.