How to determine if (remote) sensor is visible?

[originalfoo]

Hi,

I've just written my first sensor mod (github) for EvoGUI and in the on-tick handler I was thinking how nice it would be to have some way to know whether the sensor is currently displayed or not (otherwise, no point in updating the sensor data). This may already be possible (let me know if it is) but I've only just scratched the surface of the Evo codebase and didn't see anything yet.

Maybe Evo could register custom event, 'sensor-toggle' - mods get the numeric event id via remote API and hook to the event. When sensor is shown/hidden, the event fires with a table payload such as:

{ event = 'sensor-toggle', sensor = '<sensor-name>', active = true|false }

That way I can set a local variable when the event fires, and in my on-tick handler rapidly exit out if the sensor is not currently visible.

[narc0tiq]

That sounds interesting; I never thought of that use case (and it might be more code than you'd expected -- remember two cases: sensor may be set to always visible OR sensor may be set to 'when expanded' and the interface is expanded), but it would be fun to write, so sure!

(Actually, brainstorming time -- how about if EvoGUI just raised a "request-sensor-update" event that remote sensors could subscribe to? Then they don't have to have an on_tick at all if they don't need it for something else.)

Probably will write it exactly as you described, to be honest. In fact, if you want to write it and pull request it, that's just as good -- I really don't know when I'll be able to bite off a chunk of time to get it done.

---

Semi-off-topic, I peeked at your code, and I noticed the statement game.tick % 10 -- every 10 seconds -- this is not as you expected based on the comment: it's every 10 game ticks, and there are 60 ticks (aka updates) in a second if you're maintaining 60 UPS. Thus, that's 6 times per second -- you probably meant game.tick % 600.

Also, I saw you're only tracking player 1, but since I haven't fixed #58, that's about as good as it gets at the moment; it might be worth making a note that your sensors are single-player-only (and subscribe to get notified when I close that other issue).

[originalfoo]

how about if EvoGUI just raised a "request-sensor-update" event that remote sensors could subscribe to?

I was actually just coming back to suggest something like this! Yes, Evo could send an event when it wants a sensor update. Thoughts:

• On receiving event, how would sensor send data back to Evo?
• What happens if sensor doesn't want to send new data? Should it be forced to recalculate?
• The players for whom the sensor is shown should be listed in the event as an array - this would allow the sensor to loop through provided array and generate data for those players, rather than all players.
• It would allow Evo (or player via Evo settings) to determine sensor update rate - eg. user might want to limit updates to 1 per second, or 1 every 10 seconds, perhaps even on a sensor-by-sensor basis. When mod registers a sensor, it should be able to define the desired initial update rate.
• Evo could potentially assess the performance of sensors and auto-throttle them?
• It would be nice to have transient sensors - eg. mod realises it needs to tell player something urgent, activates transient sensor for a while. (I'm making a radio network mod, and it's masts can catch fire if improperly used, so I'd want transient to warn user about that. User would be able to choose if/how transient is displayed via EvoGUI sensor setting).
• It would be nice if mods could use EvoGUI for their general mod settings. So, while registering a sensor, the mod could also provide a remote api namespace and key relating to sensor-advanced settings button or something like that. In Evo, user clicks setting button for sensor and if that namespace + key is specified, an additional button appears (with localised text from mod?) which when clicked does remote call.

Semi-off-topic, I peeked at your code, and I noticed the statement game.tick % 10 -- every 10 seconds -- this is not as you expected based on the comment: it's every 10 game ticks, and there are 60 ticks (aka updates) in a second if you're maintaining 60 UPS. Thus, that's 6 times per second -- you probably meant game.tick % 600.

Oh wow, I thought ticks were per second. I'll update that. I've just been adding in localisation, etc so will add that change in now.

[narc0tiq]

On receiving event, how would sensor send data back to Evo?

Exact same method as currently -- sensor makes remote call to update sensor data.

What happens if sensor doesn't want to send new data? Should it be forced to recalculate?

Not at all, we keep the same method as now and just write in whatever we have; if nobody updated it, it'll remain whatever it was before.

The players for whom the sensor is shown should be listed in the event as an array - this would allow the sensor to loop through provided array and generate data for those players, rather than all players.

Agreed; in fact, if we do it right, the sensor can just populate the same data structure it received and post that in its update call.

It would allow Evo (or player via Evo settings) to determine sensor update rate - eg. user might want to limit updates to 1 per second, or 1 every 10 seconds, perhaps even on a sensor-by-sensor basis. When mod registers a sensor, it should be able to define the desired initial update rate.

That's more complicated, as you'd want the per-sensor update rate to be separate from the main GUI update rate, so you then want a table like

sensor_updates = {
    [10] => {"this_sensor", "that_sensor"},
    [15} => {"that_other_sensor"},
}

-- it's a whole new data structure to keep track of, for an uncertain benefit, since updates still won't be shown any more often than the GUI update rate.

Evo could potentially assess the performance of sensors and auto-throttle them?

I'm not convinced the data exists or is worth managing; sensors shouldn't be that complicated.

It would be nice to have transient sensors - eg. mod realises it needs to tell player something urgent, activates transient sensor for a while. (I'm making a radio network mod, and it's masts can catch fire if improperly used, so I'd want transient to warn user about that. User would be able to choose if/how transient is displayed via EvoGUI sensor setting).

Technically, you can create and delete sensors on the fly, if memory serves, so the only remaining hurdle is having them automatically shown. That's requested at #61, and would totally be worthwhile.

It would be nice if mods could use EvoGUI for their general mod settings. So, while registering a sensor, the mod could also provide a remote api namespace and key relating to sensor-advanced settings button or something like that. In Evo, user clicks setting button for sensor and if that namespace + key is specified, an additional button appears (with localised text from mod?) which when clicked does remote call.

Um. I thought I had that as a plan for future enhancement, but it turns out I don't. New issue ahoy!

[originalfoo]

Agreed; in fact, if we do it right, the sensor can just populate the same data structure it received and post that in its update call.

Yup - reuse same tables, just update the values. IMO localisation should be mandatory as it will promote this approach.