LuaCircuitNetwork.signals_changed

[DaveMcW]

I would like a read-only boolean property on LuaCircuitNetwork to tell when the contents of a circuit network have changed. I believe this already exists internally, it just needs to be exposed to Lua.

The use case is controlling modded buildings through the circuit network. With a fast way to see if a circuit network has changed, a mod can skip the time-consuming comparison of individual signals on ticks where nothing happened.

[Hares]

Great suggestion.
+1 on that

[Rseding91]

Changed compared to what?

[Nidan]

Judging from the final sentence, compared to the previous tick.

[boskid]

Such value is indeed available but it is not save-load stable and as such i am not allowed to expose that without risks of desyncs. Due to way circuit network is implemented in 1.1, it is recomputing some values during first update after save was loaded (by client) even when those computations are not required on server. There are also some annoying behaviors related to this value as it may be spuriously set by some entities (i think roboport may be one of them) every tick even if the signals are not changing so it may not be useful in some cases. I may reconsider this once 1.2 would be released since the circuit network in 1.2 is implemented slightly differently causing less spurious notifications about changed signals and the value in 1.2 is save-load stable making it possible to be exposed here.

[braxbro]

I would like a read-only boolean property on LuaCircuitNetwork to tell when the contents of a circuit network have changed. I believe this already exists internally, it just needs to be exposed to Lua.

Why not make an event out of it?

[mrvn]

I would like a read-only boolean property on LuaCircuitNetwork to tell when the contents of a circuit network have changed. I believe this already exists internally, it just needs to be exposed to Lua.

Why not make an event out of it?

That would generate an event for every single circuit network that has a change. You can't just listen to events on a specific circuit network (which would be really great).

Maybe there could be a new CircuitNetworkListener prototype, a new entity, that generates events. That way you would only get events where that entity is placed and connected.

[Hares]

That would generate an event for every single circuit network that has a change. You can't just listen to events on a specific circuit network (which would be really great).

Maybe there could be a new CircuitNetworkListener prototype, a new entity, that generates events. That way you would only get events where that entity is placed and connected.

I suppose an per-entity or per-entity-prototype event could also be a soultion, since it is the most-used case.
Plus, unlike per-network event, this will allow not worrying about player rewiring their stuff or scripts performing multiple (un)wire actions on the same tick.

[scruffyvoltherder]

+1

This would be very useful

[Yodo]

Any chance for Factorio 2.1?

[protocol_1903]

I'm working on a mod library for this use case since i doubt it will see proper implementation in the engine. Will be coming soon, hopefully.

mod link for those interested

[Hares]

I'm working on a mod library for this use case since i doubt it will see proper implementation in the engine. Will be coming soon, hopefully.

mod link for those interested

I appreciate your determination.
However, the whole purpose for this request is to not perform on_tick events for each monitored network.

[Yodo]

However, the whole purpose for this request is to not perform on_tick events for each monitored network.

I'm pretty sure this request won't change that. You'll still have to check the value of is_circuit_network_changed every tick, it's not an event.

[Hares]

However, the whole purpose for this request is to not perform on_tick events for each monitored network.

I'm pretty sure this request won't change that. You'll still have to check the value of is_circuit_network_changed every tick, it's not an event.

Yeah, that's my point. The idea behind this feature request is to subscribe to a specific circuit network to reduce on_tick operations.

[Yodo]

An event on_signals_changed is not the same as a readable value /attribute is_signals_changed, I thought this thread was about the latter.

[Hares]

An event on_signals_changed is not the same as a readable value /attribute is_signals_changed, I thought this thread was about the latter.

I don't see if it is remotely usable.

[protocol_1903]

I'm working on a mod library for this use case since i doubt it will see proper implementation in the engine. Will be coming soon, hopefully.

mod link for those interested

I appreciate your determination.
However, the whole purpose for this request is to not perform on_tick events for each monitored network.

This is not going to be an on_tick per network. It will be a circuit network monitor that fires events when triggered.

[Gergely]

Some way to monitor changes would really be appreciated. I am working on adding custom control behaviour to an entity and I found no way for my code to sleep until the circuit inputs to the entity change.

My suggestion is to add a function to LuaCircuitNetwork that enables a monitor on it, causing a new event type to be fired every time the signals on the network change. And possibly with support for signal filters because many control behaviours only use one signal or one signal kind. (Set value controls use specific signals, while something like setting an item filter only cares about item signals.)

Because this Lua object is associated with a connection on an entity, if the connection is removed it could be deregistered automatically. If we combine this with the suggestion to add wire connected/disconnected events (698828) it would allow the scripted control behaviour to be completely passive.

[protocol_1903]

My suggestion is to add a function to LuaCircuitNetwork that enables a monitor on it, causing a new event type to be fired every time the signals on the network change. And possibly with support for signal filters because many control behaviours only use one signal or one signal kind. (Set value controls use specific signals, while something like setting an item filter only cares about item signals.)

Simply, no. Events will not be fired 'because an object exists' because the object doesnt exist, it just is a reference to a luaobject that may or may not exist. Additionally, having conditional event firings will break determinism with the mod which is a no-go. Also also, mods cannot have events fired just for that mod. Events are always fired, for every mod.

You could have some method of registering a listener to a specific circuit network which would fire said events (similar to script.register_on_object_destroyed), but there wouldn't be an object associated with it and it would fire events for every mod.

[Gergely]

First I would like to note that 698828 precedes this. There is no point to monitoring signals if we cannot even tell when there is something to monitor in the first place.

With that out of the way, let me get down to proposing an actual API:

New function: LuaCircuitNetwork::register_on_change
New event: on_circuit_network_signals_changed.

Calling register_on_change sets a flag on the LuaCircuitNetwork object: The next time the signals change, (the values returned by LuaCircuitNetwork::signals change) the flag is cleared and the on_circuit_network_signals_changed event is fired for all mods that listen to it. The event data will contain a reference to the LuaCircuitNetwork object, enabling retrieval of the owning entity.

The flag persists through a save and load and it is not possible to clear it from the script side. It is cleared before the event is fired however, allowing mods to independently reassess whether they still need to listen to updates and set it again if they do.

Why fire the event for every mod? Well every event in the game is fired for every mod that listens and this should be no different. Mods have to filter events depending on what information they actually care about. Also, like all events I am not proposing to make this event registration somehow persist between save and load. Mods have to reregister it like all events. However the flag on the LuaCircuitNetwork object should persist so mods do not have to track every object they care about in storage and set the flags again in on_load. (Where such code would most likely go.)

Why no flag-per-mod? Because checking one flag per mod is slow and could complicate memory management. I cannot make any claims on what kind of optimizations are possible. One flag seems simple. However it has to behave the way it does to avoid interference between mods. Multiple mods can set it, which is still equivalent to setting it once. Clearing it before the event gives an opportunity for all mods to individually decide whether they still want to listen to the event on the particular object.

One flag per SignalIDType could be considered. The idea is simple: register_on_change accepts an optional SignalIDType and only sets the corresponding flag. All flags by default. Signal changes are considered per SignalIDType: A flag is only cleared when a signal with the corresponding type changes and the event is only fired when any flag is cleared. An EventFilter could be added to filter on the type of signals affected or even on the name/type of the entity the LuaCircuitNetwork belongs to. This is useful in case a script-defined behaviour only cares about one type of signal. For example a script-defined item filter will only care about items, a fluid filter only cares about fluids and so on.