Previously OR and Activation Modules were used to indicate (not) full and (not) empty, which I found both more intuitive (I wouldn't exactly call it
intuitive, only
more intuitive than what we have now), and more useful.
Recently, the system has been changed to indicate success or failure of the storage module pulling from other storages, ie. they don't signal empty/full anymore, but only whether they were able to
complete a pull,
and only if there actually are more items to pull from - if the source storage is empty, "fail to pull" would be signalled, regardless of whether the sink storage is full or not.
That's not very helpful if you're filling the storage say, from a linked salvage computer, because then it doesn't
pull from anywhere, and thus will never emit a signal.
You could add a second storage that pulls from the salvage buffer, but this breaks if you use docked containers to collect the salvage; the source storage they pull from (across the rail/docker connection) must not be set to pull. Again, if a storage doesn't pull, it can not update connected logic, and you can not detect its state... but if it doesn't pull, it can't get items out of its source.
Even if it could, the storage on the container doesn't count as pulling from another storage because it's pulling through the rail, and so
it would fail. Maybe add another intermediate storage...?
I can only assume the original implementation had other issues, most likely performance scaling, so changing back may not be an option. As is obvious from the latest patch notes, Schine
are working on ironing out storage related issues.
A storage controller would be simple in concept, flexible in application, and complementary to the current system - it can be used to signal full, empty, or intermediate
states, and the current system can signal item
flow once it gets fixed.
see also
T84 Logic blocks next to storages and shipyard computer do not get triggered and
T914 cargo area - does not detect full state anymore, among others.