Add a Custom Virtual Signal as Command to Update Chests

[Hoochie63]

Hi!
Is it theoretically possible to create a virtual signal for the "Update selected logistic chest" command and how difficult is it? That is, if a virtual signal is sent, it triggers the "Update selected logistic chest" command - is this even possible?

Why such a question?
The thing is that I need the chests to be updated automatically, without user intervention, that is, so that there is no need to manually run the chest update commands when deleting a recipe or selecting a recipe.
In essence, the problem is that updating chests is additional actions on the part of the player, and since the game is still about automation (after all, users strive for this, so that everything works without user intervention), I would like it to be like that here too :)
A virtual signal, as a command, can be installed on the combinator, which in turn checks whether the machine has a recipe or not, and sends a one-time command-signal to update the chest.
This is also a kind of automation of the process, although a little complicated :)

[Hoochie63]

On the other hand, if this could be implemented, it would lead to a more interesting user experience, when he could create a whole system on his own base, when the automation of the process would have a more pronounced form, and would require certain skills from the user to create it (that is, he would have to think about how to organize it correctly:) )
It is not as simple as putting a chest, and everything works for you by itself, but you will still have to put in some effort to organize a truly "automated" production.

[Daschi1]

So to recap: you’d like to set up a circuit/combinator logic that detects, for example, if a recipe on a machine has changed, and then outputs a virtual signal to update the chest (and this signal would connect to the chest via a wire—is that correct?).

Creating a virtual signal is definitely possible, as outlined in the Lua API. However, I’m not entirely sure how to handle the refresh action upon receiving the signal. Specifically, I’m uncertain whether it’s possible to listen for arbitrary signals on a chest (or any other entity). I’d need to investigate this further.

A potential “utopic” solution might be adding an extra option in the circuit condition section of the logistic chest—something like a "refresh" option. This would allow the user to define the condition that triggers the refresh. However, I’m fairly certain that this level of extension isn’t currently supported by mods. Again, I’d need to check and confirm.

[Daschi1]

I might do some tinkering with this if I find the time, but it’s unlikely to happen before the weekend. Based on my initial glance at the docs, implementing the "utopic" solution seems unlikely, as it doesn’t appear to be supported. If that’s the case, it would require a method to check within the on_tick function, which is exactly the approach I’ve been trying to avoid—hence the current design of using a custom input to refresh.

I could add an option for this feature, but I already feel like the available options are becoming somewhat bloated. This situation isn’t improving, especially with at least two more options likely needed to address an issue with furnaces (see this discussion regarding stone/steel furnaces and logistic chests removing coal). While I plan to refactor parts of the special behavior section (e.g., the rocket silo and artillery turret integrations) to make it more flexible and extensible, I’m still not thrilled about adding yet another option.

The next question is whether this feature should be enabled by default. Will the average mod user care enough about it to justify enabling it by default? On the other hand, not enabling it by default could hide this already niche feature even further, potentially missing users who might find it useful.

If I do go down the path of implementing this signal behavior, it raises another question: why not make it fully dynamic in the first place? If we already have the update-on-signal logic running each tick, why not add checks to make the manual refresh obsolete? For example, chests could update automatically when a recipe changes. This approach might also eliminate the need for special integrations entirely, as it could directly check machines at runtime for fuel, items, etc., and act accordingly—avoiding reliance on predefined lists.

These are just my current thoughts on the topic. I wanted to share them to be transparent about why this feature may or may not happen.

[Daschi1]

related: https://mods.factorio.com/mod/automatic-logistic-chests/discussion/678775786ef0c20318c75fd7

[Hoochie63]

Creating a virtual signal is definitely possible, as outlined in the Lua API. However, I’m not entirely sure how to handle the refresh action upon receiving the signal. Specifically, I’m uncertain whether it’s possible to listen for arbitrary signals on a chest (or any other entity). I’d need to investigate this further.

The chest has an option to be turned on by different signals, perhaps in this case the command should be triggered - when the chest receives a virtual signal. Something like: if the virtual signal "update chest" = 1, run the command "update chest".
Unfortunately, I don't have even basic knowledge, so I give this example.

Yes, I understand your thoughts, but I will also hope that in the course of reflection you will come to the implementation of this logic :) Hope is our everything! :))))

[Daschi1]

Yes, this just gave me an idea: I could potentially make it so that if the chest is connected to a circuit network, and its enabled state is set by the network, it would refresh its requests. That should be possible, though it would definitely require some significant changes and effort to implement.

[Hoochie63]

:)))))

[Daschi1]

^^ I'll do my best, but I can't promise anything before the weekend.

[Daschi1]

Hi, just to keep you updated—sorry this is taking longer than anticipated. Life has gotten busier now that we’re further into the year, and I haven’t been able to dedicate as much time to this as I’d like.

I’ve just released another feature for the mod, along with a bugfix, but unfortunately, I haven’t gotten to this feature request yet. I’m hoping to take a closer look next weekend, though there’s a potential bug I’ll need to prioritize first (if confirmed).

Thanks for your patience!