Just a thought. Instead of using on tick handlers could have an invisible part of the entities be a radar type (no range) that 'charges' via its scanner to complete a cycle, then just listen for when that completes. People can stop it by cutting power to it, you can have different tiers that have different power investment and charge rate to charge, etc... Would be even less UPS usage.

Nice, that could certainly help during a cycle.

Any ideas for detecting circuit network green signals and full inventories without on-tick?

There is an event for when a radar cycle completes, if you listen for that and filter based on your own invisible radar entity type (which you place/remove with the appropriate creation/destruction events on top of the existing building, if you can't just replace that one outright) then in 'that' callback you can read the signals, inventories, do whatever, and it will only ever be called for the specific invisible radar entity that completed its cycle, even if only once every 20 minutes or however long you have it work based on its prototype. :-)

There are a number of UPS helping tricks like that.

Sounds like my next weekend will involve a new git branch for experimentation :)

There are a number of mods that follow a similar style. For example Natural Evolution Buildings mod's Artifact Collector is made up of 3 entities, one being an operationaless turret (used to display the range overlay), a passive providing logistics chest, and a radar. The turret is the item part so when you select an artifact collector item via that mod it shows the range, and when you place it then it has an On_Built function registered to each of the build event callbacks, it's full event registration set is:

script.on_configuration_changed(On_Config_Change)
script.on_init(On_Init)


local build_events = {defines.events.on_built_entity, defines.events.on_robot_built_entity}
script.on_event(build_events, On_Built)

local pre_remove_events = {defines.events.on_pre_player_mined_item, defines.events.on_robot_pre_mined}
script.on_event(pre_remove_events, On_Remove)

local death_events = {defines.events.on_entity_died}
script.on_event(death_events, On_Death)

script.on_event(defines.events.on_sector_scanned, function(event) ... end)

When On_Built is called it tests if what is being built is if (entity.name == "Artifact-collector-area") then and if so then it destroys that entity (you can of course just leave it, it destroys it because it only needs the turret range display when it is in item form) then spawns two other entities in its place:

            entity.destroy()
            chest = surface.create_entity({name = "Artifact-collector",
                           position = position,
                           force = force})
            position_r = {position.x + 1, position.y}
            entity = surface.create_entity({name="Artifact-collector_r",
                            position = position_r,
                            force = force})

The Artifact-collector is the provider chest and the Artifact-collector_r is the radar with no range.

Consequently in the On_Remove and On_Death callbacks it handles removing the corresponding other part of the entity as well (this mod does it via a global lookup table but you can easily just do an entity iteration on that one tile to find the corresponding matching part so you don't need to store a global lookup table).

In addition, the defines.events.on_sector_scanned callback is what is called when a radar finishes a scan cycle (which will of course be slowed down if power is not fully satisfied and other useful aspects like that), of which you just test if it is 'your' fake radar type thing and handle it accordingly, which for the Artifact Collector it just accumulates them in a list and then process through the list in an on_tick handler (which is useful for the artifact collector since players have a tendency to spam them by the hundreds to thousands, so it is useful to limit the amount called per frame), but in general you'd just handle the processing of the item right there (unless, of course, you are expecting a huge amount and they cycle quickly, which this mod shouldn't worry about, both because it doesn't world-scan like the artifact collector scans for artifacts, and since the cycle periods are long).

And even more tricks than that. :-)

Cool, thanks, that sounds like how the dual energizer and inventory entities that make up the teleporters are being handled, so maybe not much I can improve there. Reassuring to hear it's a wide-spread practice :)

The catch I keep hitting is also responding in close-to-real-time to incoming green signals that start a cycle explicitly, as well as detecting when an inventory is full and ready to send implicitly. Currently it's between 1 and 3 seconds delay due to an infrequent on_nth_tick check. Hopefully not a big deal since, as you say, cycles periods are long -- what's an extra 3s waiting for one to start?

The catch I keep hitting is also responding in close-to-real-time to incoming green signals that start a cycle explicitly,

Any kind of LUA reading somewhat-real-time circuit tests are costly, honestly that would be a feature I'd drop and just force the user to work based on the implicit cycles, which if they want to cut off then they can just cut off the power to the thing. ^.^