[boskid][1.1.104] "Set Requests" circuits on requester chests break when the chest changes forces, but come back on load

[raspberrypuppies]

Problem:
Requester chests lose their "set requests" ability IF its set by a circuit condition AND the chest changes forces. They regain it when reloading the save file (possible desync bug).

I noticed this when trying to use set requests using my rp_steam_roboports mod + SE. The requester checks for my rockets broke every time they ran out of steam and changed forces.

This is reproduceable in vanilla, although there's no way for this happen without console commands

How to reproduce:

1. Create a requester chest, connect a wire to a constant combinator. Use "set filters" to request what's in the circuit

Before.jpg (159.54 KiB) Viewed 1072 times

2. Change the requester chest's force, ex:

Code: Select all

/c for _, v in pairs(game.player.surface.find_entities_filtered{name="logistic-chest-requester"}) do
  v.force = 'neutral'
end

3. Change it back, ex:

Code: Select all

/c for _, v in pairs(game.player.surface.find_entities_filtered{name="logistic-chest-requester"}) do
  v.force = 'player'
end

4. The chest will still have the "set filters" option, but nothing available. The little connection light will also stay red as if there's no connection.

after.jpg (96.41 KiB) Viewed 1072 times

after chest UI.jpg (172.02 KiB) Viewed 1072 times

5. Save & re-load the game, the requester chest will work again

[boskid]

You are right, that is a desync.

From a quick investigation it looks that when logistic container changes force, it destroys logistic point of that logistic container and since logistic point stores current filters they are simply lost. There is a code that is supposed to preserve filters when changing force but it restores filters using a generic set filter function which rejects setting filters when filters are set by control behavior and in this case they indeed are set by control behavior. This issue fixes itself if the signals on the circuit network change because control behavior sees a change and sets correct filters. Filters fixing themselves on load is a quirk of circuit networks in 1.1 where they are always considered changed after load and there was assumption that an extra update would not change game state however here it does as it sets the filters.

I know that in 2.0 there is no longer this fixing on load happening for circuit network and also i verified that in 2.0 when filters are restored they are using unconditional code which is able to set filters even when logistic container has filters set by control behavior so the issue is fixed for 2.0.