[2.0.44] Regression: "no-automated-item-removal" no longer allows entities to be assigned as pickup_target by script
Posted: Wed Apr 09, 2025 10:47 am
1. What did you do?
In 2.0.43 and earlier, the "no-automated-item-removal" entity prototype flag prevents inserters from automatically selecting an entity as a target for pickup, while allowing their manual assignment via the api using pickup_target. This is useful, as it allows a mod to easily control access to an entity, protecting it against unintended interaction that is not explicitly assigned. Mods that implement entity logic with the intention of behaving consistently with the base game can easily check for and respect the presence of this flag when selecting other entities to interact with, especially when those potential targets are controlled by other mods whose functionality may be disrupted.
2. What happened?
The fix to the edge case described in viewtopic.php?t=127774, implemented for 2.0.44, seems to be use of this same entity prototype flag, "no-automated-item-removal" to determine whether an entity is "a valid pickup target" at all. This breaks the use case mentioned above, as the only supported behaviors now are "no access" or "open access", requiring additional event handling to check for and prevent unintended access where before it was trivially guaranteed by the engine.
3. What did you expect to happen instead? It might be obvious to you, but do it anyway!
My expectation was for the existing functionality of that flag to remain intact (as it still is with "no-automated-item-insertion"), especially as the primary argument towards the behavior in the earlier bug report being incorrect was that it imposed an additional burden of event handling on modded entities, simply for intending to maintain a consistently correct state while potentially interacting with entities outside the mod's control. The prior behavior of this flag was a very useful tool to that same end.
I would also understand if this kind of usage were never intended at all, in which case I will re-open this as a modding interface request instead. I do appreciate the fix to the other issue and I'm sorry to bring up inserter behavior again already. I am relatively new to using the API and I'm sure I'll stop fussing so much over edge cases eventually!
I've attached a minimal example mod and save file (using the EditorExtensions mod) to demonstrate the difference in behavior between 2.0.43 and 2.0.44. Remove and replace the inserters using the provided blueprint.
In 2.0.43 and earlier, the "no-automated-item-removal" entity prototype flag prevents inserters from automatically selecting an entity as a target for pickup, while allowing their manual assignment via the api using pickup_target. This is useful, as it allows a mod to easily control access to an entity, protecting it against unintended interaction that is not explicitly assigned. Mods that implement entity logic with the intention of behaving consistently with the base game can easily check for and respect the presence of this flag when selecting other entities to interact with, especially when those potential targets are controlled by other mods whose functionality may be disrupted.
2. What happened?
The fix to the edge case described in viewtopic.php?t=127774, implemented for 2.0.44, seems to be use of this same entity prototype flag, "no-automated-item-removal" to determine whether an entity is "a valid pickup target" at all. This breaks the use case mentioned above, as the only supported behaviors now are "no access" or "open access", requiring additional event handling to check for and prevent unintended access where before it was trivially guaranteed by the engine.
3. What did you expect to happen instead? It might be obvious to you, but do it anyway!
My expectation was for the existing functionality of that flag to remain intact (as it still is with "no-automated-item-insertion"), especially as the primary argument towards the behavior in the earlier bug report being incorrect was that it imposed an additional burden of event handling on modded entities, simply for intending to maintain a consistently correct state while potentially interacting with entities outside the mod's control. The prior behavior of this flag was a very useful tool to that same end.
I would also understand if this kind of usage were never intended at all, in which case I will re-open this as a modding interface request instead. I do appreciate the fix to the other issue and I'm sorry to bring up inserter behavior again already. I am relatively new to using the API and I'm sure I'll stop fussing so much over edge cases eventually!
I've attached a minimal example mod and save file (using the EditorExtensions mod) to demonstrate the difference in behavior between 2.0.43 and 2.0.44. Remove and replace the inserters using the provided blueprint.